Re: [PATCH] image_types: preserve rootfs if mkext234fs() fails

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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 <sgw@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
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