From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by mail.openembedded.org (Postfix) with ESMTP id 9FEA578433 for ; Wed, 20 Dec 2017 09:51:15 +0000 (UTC) Received: from hex ([192.168.3.34]) (authenticated bits=0) by dan.rpsys.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id vBK9p8mW030713 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 20 Dec 2017 09:51:09 GMT Message-ID: <1513763468.16507.71.camel@linuxfoundation.org> From: Richard Purdie To: Tom Rini , Saul Wold Date: Wed, 20 Dec 2017 09:51:08 +0000 In-Reply-To: <20171219205438.GN14220@bill-the-cat> References: <20171219201148.19828-1-sgw@linux.intel.com> <20171219205438.GN14220@bill-the-cat> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.99.2 at dan X-Virus-Status: Clean Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH] image_types: preserve rootfs if mkext234fs() fails X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:51:16 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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 > > --- > >  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