From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a5d:46d0:: with SMTP id g16mr41547560wrs.229.1593113238532; Thu, 25 Jun 2020 12:27:18 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:13:: with SMTP id 19ls3303399wma.0.gmail; Thu, 25 Jun 2020 12:27:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1j8ycvmI3RazHPcBfqxBaS53S7jDYDzI9OgFhG+4QIlDguqmbUayZEqv5YDvuI1cDSg4z X-Received: by 2002:a7b:ce14:: with SMTP id m20mr5466934wmc.129.1593113238010; Thu, 25 Jun 2020 12:27:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593113238; cv=none; d=google.com; s=arc-20160816; b=XyBnqZ1VkZAkNBQtGdFCTXXwbeSrQckzfBSn71/Xq3fr6c8foPkc+1TkH14P9olSDH RYr8C+AMK9EVFppStVAdAjk/EgFxjWHfh9FMsB6iJtYCr2MobdKPAZmIjcPo5Ri4PgUE WPQ5F/f8L8ybslNaHwY/opgIF0hjnYVDE67hQrecvmtfRiZoiYmoqPgmVyMLewt3/sM7 IX4e3iWGwEaTl2P/25EtA1G9sadnJEtUqMdytg9AaREQ11IAzC5AUStmEapza5OQdytp q9Frq51sPcKnAkeyQsvv6tSl5qI8545wmmSYo1PsCodcZT9UzHxR893GegmMO19FnNk2 d/qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=4dkd49/Lrtc3KpHaUMevRumc11UdjPeydGauBlxA9G4=; b=ls2jdDJVMTpnhEJhIP72YrvWxBczxhPRN62dvUfHs3GOU6lk3vDxnnztLlWxFjFfPX YKZZINewupKjm1EFhtW97pfwEp+59OgLsEI7drgxM5Pna63CSXO2zyom953Ult4/fP8C C2fIU4Q2in41fSKC6GR82tD2qGhNRF4YtvwG7DMM/itwu7VyVkkXTeBlKJCSKKzSsB5y XsGp966+GSZU+ujQCwVjAhTXWW5scCc6yoEWmWsk10cvtJ8x7hFXpGy5Sd/FJpR/gMmX 9Zjvm9sKeZgqbMGDi7RpqQ+6/j1+oaWO5u9qFfDnE5RQEcFzqnmc1yLdd8yH3VUFGu8H X2Nw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@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 g141si569505wmg.0.2020.06.25.12.27.17 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 12:27:17 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 05PJRHrL028572 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jun 2020 21:27:17 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.33.82]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05PJRGvx031638; Thu, 25 Jun 2020 21:27:16 +0200 Date: Thu, 25 Jun 2020 21:27:15 +0200 From: Henning Schild To: Harald Seiler Cc: Jan Kiszka , , Claudius Heine Subject: Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing Message-ID: <20200625212715.692fda49@md1za8fc.ad001.siemens.net> In-Reply-To: <20200625212354.55d907b3@md1za8fc.ad001.siemens.net> References: <20200625153351.3402179-1-hws@denx.de> <20200625184822.236ff069@md1za8fc.ad001.siemens.net> <91ce92c15d267e4836ab4d9de2870bc8e6f6dfa1.camel@denx.de> <20200625204307.0aede1b9@md1za8fc.ad001.siemens.net> <20200625212354.55d907b3@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 8Ce3J+ne3RhY Am Thu, 25 Jun 2020 21:23:54 +0200 schrieb "[ext] Henning Schild" : > Am Thu, 25 Jun 2020 20:43:07 +0200 > schrieb "[ext] Henning Schild" : > > > Am Thu, 25 Jun 2020 19:24:30 +0200 > > schrieb Harald Seiler : > > > > > Hello Henning, > > > > > > On Thu, 2020-06-25 at 19:02 +0200, Jan Kiszka wrote: > > > > 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. > > > > > > For reference, this is the exact code: > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ > > > "image_postprocess_generate_uuid" > > > image_postprocess_generate_uuid() { sudo sed -i > > > '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release' echo > > > "IMAGE_UUID=\"${IMAGE_UUID}\"" | \ sudo tee -a > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > sudo -E chroot '${ROOTFSDIR}' \ > > > update-initramfs -u > > > } > > > > If /etc/os-release goes into the initrd we have the issue with > > image_postprocess_mark in isar, a valid reason for a merge. > > But that is not the case. You re-create the initrd in your layer so it > might just be your problem! How about we discuss the IMAGE_UUID > upstream together with the reordering? Or do we need the "update-initramfs -u" for image_postprocess_mark? If so that should be done as a patch in this queue, you will get your reordering for IMAGE_UUID in your layer if you decide to keep that downstream. Henning > Henning > > > > > 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. > > > > > > I think this patch addresses an issue in isar itself. There is no > > > reason for copy_boot_files() to run before the postprocessing > > > does. I've checked through the git history and the reason this > > > relationship was introduced was a bigger refactor of the task > > > dependency chain. It does not seem to be intentionally this way > > > from what I can tell. > > > > Ok, sounds fair. > > > > > The other way around makes more sense, in my opinion. As stated > > > in the commit message, postprocessing might do an update to the > > > initramfs (as seen above) and this change needs to be reflected in > > > the deployed initramfs as well, instead of silently only living in > > > the version that is part of the rootfs. > > > > > > I also checked all existing postprocessing commands and did not > > > see any that assume to be run after the boot files have been > > > deployed. > > > > I just worried about people abusing postprocess for changes that > > should be packages instead. Thanks for going into detail! > > > > ACK. > > > > Henning > > >