From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6767012587809800192 X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr6813159ljo.240.1575574313389; Thu, 05 Dec 2019 11:31:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:cbce:: with SMTP id b197ls415524lfg.5.gmail; Thu, 05 Dec 2019 11:31:51 -0800 (PST) X-Google-Smtp-Source: APXvYqy3meYOVKWdfKIPt2LekXFK5abEZhZfGAsU4jt22Ua75Hv93zt8b1RndxdsfO1yhd07pgGO X-Received: by 2002:a19:7015:: with SMTP id h21mr5939129lfc.68.1575574311717; Thu, 05 Dec 2019 11:31:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575574311; cv=none; d=google.com; s=arc-20160816; b=eMbNMSQn83ianrwJPdnwfOjLz3JBLBmofggW41NgugnG7hPBLcD0H4lInKtlWyuZ/Q x4n1IP6d8qMPtRIPDFWiA3jOWPO5uaSCQp0hmLnvXHA6p3K9XxelJwvQKk1hBqaFCjsv oyuNTMABVK9gOvalmmguxoh3W/nglle5KIq8shD/CiIi0G8hrMhmya9oiPN3UnI8PYz5 Qp+pWoT8bzoh/CQ+/Se+gipNLraYLeQgUKfmt76HLmf3CtrpaTRaso/43stR8aBN/tpY uRg4xVdZSllzx0IENbK+T0tfKaUPLH508SQh9Tm3sTeo64YD3IKg4oOHtYhYdkSRdDrK QBZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=Ggdc+k0q0RhHooo859th6dbmFh7GPpvYnGp4CVtz9nw=; b=eflYBTQeWtpZ1qWXa05LA0nCCMLqqoo79gye568vfnqz0iFV/vll7U1kCyz/ApfZqz Hg//fMwbWDVL3oEIQlZ+n+vW7Wo5n+e3ZcIN4cETdU5cQat+F02jzPRDanmAjwOPTTW7 r4Ap3mVZdkLUc9jUvBt8gC6sMYo9DYLlshqz3GxTMOF3numiqhJJVq4GXb/sbvnhmOt+ uGmDsN61C6fFw/SaLbIjL6zoy7CurJjpdoR/ITmSEK7BqtOhUhYLnZ9Dfzwoz2Om12MD qqZPxBfm8Z83heN5jP6Z8qoCIoMsUYROvhHq4wtij8Y5CvmgWLdVkFY0oFA2P0dLZ24a 6XIQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id u5si612586lfm.0.2019.12.05.11.31.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2019 11:31:51 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id xB5JVnRK031325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Dec 2019 20:31:49 +0100 Received: from [167.87.4.146] ([167.87.4.146]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id xB5JVmO5026199; Thu, 5 Dec 2019 20:31:49 +0100 Subject: Re: [PATCH] targz-img: Ignore tar exit code 1 To: Vijai Kumar K , Quirin Gylstorff Cc: isar-users@googlegroups.com References: <20191205174441.16406-1-Vijaikumar_Kangarajan@mentor.com> <85e91f0a-da08-5345-a666-b3026bee4d96@siemens.com> <20191205191735.GA16912@oxygen> From: Jan Kiszka Message-ID: <7972e109-f8a0-6f21-bd00-4312610fd414@siemens.com> Date: Thu, 5 Dec 2019 20:31:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <20191205191735.GA16912@oxygen> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: SdHLaKm22C4O On 05.12.19 20:17, Vijai Kumar K wrote: > On Thu, Dec 05, 2019 at 07:04:07PM +0100, Jan Kiszka wrote: >> On 05.12.19 18:44, vijaikumar.kanagarajan@gmail.com wrote: >>> From: Vijai Kumar K >>> >>> Sometimes during packaging tar prints a warning "file changed as we read it" >>> and exits with return code 1. This is observed when we generete both >>> wic-img and targz-img together. Ignore the error. >> >> Ignoring errors is rarely a good idea. In this case, it tells you that >> you have a bug in your layer that missing a dependency. I know this >> because we once had the same issue in a product layer. So: NAK >> >> Jan > > Ah! Ok. Back to square one I guess. Its currently observed in our downstream setups > only. I have no good reason to justify it. Reproducing this issue is gonna be difficult. > Let me see if I can monitor file changes and pinpoint the exact condition. > But this is going to take a while. > > If it helps, the scenario is IMAGE_TYPE set to wic-img and targz-img is > inherited so both are executed for a build. Also, on a seperate note wic may have found a reason to modify the rootfs while integrating it. So a first shot could be making targz depend on wic completion. BTW, this sounds similar to https://gitlab.com/cip-project/cip-core/isar-cip-core/blob/next/classes/wic-targz-img.bbclass - and that class may have the same issue... > IMAGE_TYPE's functionality could be extended to provide multiple image types. > I believe we could specify only one right now. Former is more clean and particularly > useful if one wants a wic for sd boot and tar for nfsroot. Planning to take this up > next. Right, that is of general interest, indeed. Quirin has something planned around the same use case as well. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux