From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a05:6000:1008:: with SMTP id a8mr7148643wrx.416.1593110590525; Thu, 25 Jun 2020 11:43:10 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:a94e:: with SMTP id s75ls3255876wme.3.canary-gmail; Thu, 25 Jun 2020 11:43:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTmGOL5R/2xob3JLtGpidsXbVshE4su688eyeDRN1x4h4sZarzCQvZ6TGVjeQ0tD1xjUXQ X-Received: by 2002:a7b:c348:: with SMTP id l8mr5347985wmj.54.1593110589406; Thu, 25 Jun 2020 11:43:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593110589; cv=none; d=google.com; s=arc-20160816; b=lAJ4nsOkKp5Pr5EnCG29ZWIv12ivYX2GBuo/oYBg8KhbdkAVDfSN6hWCsBu5mGdsW5 pA/1oUmLqGNopmSAvM7XO9iY77kbwG2CKvpq8In0UtzvZrW5VwZt8O2CcrcdF3V65S5t NRUtODROLVpCsOVY9HEzCZob7KLYnLw2lHLhK2fAN+O9b9EUc7BRvwc0+cmNDT+5o8Ps 3eM4MC+Ax+m6N5MLRBnuNGaexVQlvfFCtVbi1CUeZu0dxvAJ8YLKBZjlDA/wGZ2+64E7 PoR0sOS5Xg1tIzGR/VyEsK6shAGeA021zXJkPE5WhwJ6INY6Lk23blh9KqgOX4qRJUbZ Qs7g== 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=lCGTI62Pr84QeEEzRCMcS+CFZsknRGpQEXBdBe+FIK0=; b=qJuSSZXbM4w2W+kAUx8AnsHFNHQslxy1t1WEvFgLR32NMGOxPb/u2WIwLyx2XZI3e0 IMb9//KbpzXoOindwtyRd0jto2Hi7/nNLb7um44/OEBuH6somO0LBeZV1wEJcvoyZhGM DS6oyyQ9FsTgp7S/J+ZjRG7uITbuxeXn17tDcKDBH9N+KaAIdNIoJHOq6kYl8oHlC7w9 zbY1kbeJmfIBMQ1h3QqLaWE7ffNo4spiPT+YwiPqx85D9ptfQ+0YD5Q3VcayDRLiMnK+ GjhdSxMBiL5JKL0HeE53oWphUAcozKUyDmLvrRGBzHaGB1y/Fi7g1YQ5wxyLMdFdEzNP owIA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id g141si565224wmg.0.2020.06.25.11.43.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 11:43:09 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.40 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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 05PIh8XP020503 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jun 2020 20:43:08 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.33.82]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05PIh7dh017367; Thu, 25 Jun 2020 20:43:08 +0200 Date: Thu, 25 Jun 2020 20:43:07 +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: <20200625204307.0aede1b9@md1za8fc.ad001.siemens.net> In-Reply-To: <91ce92c15d267e4836ab4d9de2870bc8e6f6dfa1.camel@denx.de> References: <20200625153351.3402179-1-hws@denx.de> <20200625184822.236ff069@md1za8fc.ad001.siemens.net> <91ce92c15d267e4836ab4d9de2870bc8e6f6dfa1.camel@denx.de> 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: a5SEXdjLsvg+ 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. > > 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