From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a2e:9b8e:: with SMTP id z14mr8261535lji.25.1593104537414; Thu, 25 Jun 2020 10:02:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:3047:: with SMTP id b7ls1864394lfb.1.gmail; Thu, 25 Jun 2020 10:02:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztgzU/hnm9XvFkbwTm2vSl+CmYjYLTaMnaNENPOz/xf68F72tMVvhGwM5o/kzkfOrYjol4 X-Received: by 2002:a05:6512:318f:: with SMTP id i15mr19201817lfe.203.1593104536601; Thu, 25 Jun 2020 10:02:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593104536; cv=none; d=google.com; s=arc-20160816; b=jdJwWc5ByjJ9eaaGHyZx7GADmQuyqwBSEZIWkofRjmfsBWykN9Vi0yBHstHo4Fwyzn MMoYuExYhgHDiTbMSu9Baxkwk09ZI3nOhBFFseyBRFWmtFqMzkelPkKD/bVQA+vLDMSl LebbmnSQbk8nPuXmB/DHkiLDyuOHtgfd81ILhJWgLRuWGzBU3cTUqQ940pMYQHvmZpa6 b6Mt44HMpvLYsM4I+Bio6Z6EgnwQ5P5ExDO1ayTmBoHRjz9SaV8bSf/0RH9WSo/6cPGJ 2LhRK4oYsfptcyLXUybZ+Ro0AnXrOvmqdK+AfjXucUy/HPIeUNgz7bFbG7PqE7KYtHpC TwYQ== 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=PNHXCmNEJM1rm/XePR2bbgVt9h+E9mv04kEyHFjAE+U=; b=rqfoUEfByxAmlvE7+hleNBBdf9et/CqvTfTH8h0zbSYQFGRVjeH0HJJj4b5Te87Fqc Lu5AFrJMlHvzofRiMEWsqZaC7xefY7r+n5mtj0wJebRLDUPAS1z0iG/kGFW65DPFmG8u l/JA0IMs1MCjCVhiOJrNJJ2+vs30k5JYNmOTr+rfzJ0VYVurAH1VNN+KXjyZ5G+7Fch+ 3+G24+TlaeW+usU1IPi16XHmrL9+gG9YDwrGyYBdN8azlaI1KpAkpY1xw3TS+TjBaFik osjC93om0CBAPgD977hruChHv/9ypBxdzopOc6FnUeKsTtXB/sMPefE0qXY1iLP0MoF5 T3eg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id u23si1476615ljg.7.2020.06.25.10.02.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 10:02:16 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 05PH2E40006968 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jun 2020 19:02:14 +0200 Received: from [167.87.31.95] ([167.87.31.95]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05PH2DbO006712; Thu, 25 Jun 2020 19:02:13 +0200 Subject: Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing To: "[ext] Henning Schild" , Harald Seiler Cc: isar-users@googlegroups.com, Claudius Heine References: <20200625153351.3402179-1-hws@denx.de> <20200625184822.236ff069@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: Date: Thu, 25 Jun 2020 19:02:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200625184822.236ff069@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: sNUadrj9+anz On 25.06.20 18:48, [ext] Henning Schild wrote: > Hi Harald, > > can you elaborate on those cases? The postprocessing is hacky, if the > problem is coming from your layer you should probably keep this patch > in you layer. Basically do_generate_image_uuid from https://lore.kernel.org/cip-dev/20200625141015.31719-4-Quirin.Gylstorff@siemens.com/T/#u, just modeled as post-processing hook, rather than a task. Jan > > Maybe you can point out an issue in isar itself, or explain how you got > into this situation? We can then see if your change is generic enough > for upstream. You could also provide the error-case from your layer as > an upstream feature, if that is generic enough. > > Henning > > Am Thu, 25 Jun 2020 17:33:51 +0200 > schrieb Harald Seiler : > >> In some cases, postprocessing might trigger an update of the initramfs >> which would not appear in the deployed version. Fix this by running >> copy_boot_files only after all postprocessing completed. >> >> Signed-off-by: Harald Seiler >> --- >> meta/classes/image.bbclass | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >> index 0150f2718573..21d634a8f34f 100644 >> --- a/meta/classes/image.bbclass >> +++ b/meta/classes/image.bbclass >> @@ -153,7 +153,7 @@ do_copy_boot_files() { >> cp -f "$dtb" "${DEPLOY_DIR_IMAGE}/" >> done >> } >> -addtask copy_boot_files before do_rootfs_postprocess after >> do_rootfs_install +addtask copy_boot_files before do_rootfs after >> do_rootfs_postprocess >> python do_image_tools() { >> """Virtual task""" >