From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a2e:7a1a:: with SMTP id v26mr8836999ljc.467.1593113038575; Thu, 25 Jun 2020 12:23:58 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:298:: with SMTP id b24ls1378036ljo.4.gmail; Thu, 25 Jun 2020 12:23:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+gXusgr1AACWm+HNUOHJWS170kBwdnoLVMuFLsJPbjCvhNQmEpUC8P3+g7NaPos2bWZFv X-Received: by 2002:a2e:8751:: with SMTP id q17mr9454739ljj.386.1593113037938; Thu, 25 Jun 2020 12:23:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593113037; cv=none; d=google.com; s=arc-20160816; b=SFR2UzFLsMKZ1kGV6aK8qL+W6J7ITlrXcRXXHTQF1qePDNO/Ur8Jyx0c+eDWxCGHj3 0TjI1sMqAE4r0D/sCuAPxyio3da/81jYagFd4uiHoRfWl4FXrz0G2OKvizTVbGs3wO/d axpn6lsnJ06NqpKiQBAKW2iIIpAmnwjajJw0epmgIKoPe0gfzk04VSZk9KySnISoiJ+i 8gSotzLIFAjmXGlqfi7UgNu1XNb1zcIOcS8Lwk5p8MUBQC9pjHukL7y7KUFvrATy2PrL vOynGOdawcY7ZDFKU0wbtrP8etTu8EaKqCQDq5MmENTXQIaKJUMhjraFjaqglSOeemsV LUDQ== 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=+9CGnjC10ZTTaimI+cKtixkIHYbFpzeIxhAcYuC6TbI=; b=fQLCi5Cg7WhbZm7E/wUczg5HtFwAgI01Q1y6Ll6msLcr3eZIdjn0iRk4UOPGiobr8V S1geuW86IFFdbNnmvtpadZTw6AYsMXh5SfleEPqBKrS/HsnQZVc1/46/nqbsnW7PpswI Z4rXEL4kXfkb7q+6vEmk/6tqTzeae5IC3iC/JibEO/j8MvJ/QNlljOsf3x5+hEXgRoGc L3yvMepQm/Liky/D2jl1hvJxwGri4DovTT2BkhAbbE/mNR4GjlD4lGQbK5DHGRridSF3 7e1TcG9YXJcrKhDu3zDO1dX51RSIuHHWOtcc2OPTFXwogslx7n9joksmZzS3n83T8AYc CHCA== 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 7si849272lfk.0.2020.06.25.12.23.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 12:23:57 -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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 05PJNuxQ030109 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jun 2020 21:23:56 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.33.82]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 05PJNt3u025620; Thu, 25 Jun 2020 21:23:55 +0200 Date: Thu, 25 Jun 2020 21:23:54 +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: <20200625212354.55d907b3@md1za8fc.ad001.siemens.net> In-Reply-To: <20200625204307.0aede1b9@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> 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: os7baZ9OkG6O 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? 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 >