From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a17:906:148a:: with SMTP id x10mr1611723ejc.497.1593159219593; Fri, 26 Jun 2020 01:13:39 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:6d58:: with SMTP id a24ls1319885ejt.1.gmail; Fri, 26 Jun 2020 01:13:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMkX//eaQvFkSIQ95gcYcyQScA51jWfsHhVMxGTMPXrqJWXJvUmlUrfeNRFmitJlgbMdNq X-Received: by 2002:a17:906:7283:: with SMTP id b3mr1599808ejl.163.1593159219077; Fri, 26 Jun 2020 01:13:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593159219; cv=none; d=google.com; s=arc-20160816; b=vowgM9IkGgN9tB8t8ojaxHSOQr+B8lpwiitMlEnbGQqgfYCvhiJRGVHRyUQc4ZCQ7s L2G14a5F3qCiLq1yBQBDPxDzf2GprEAWtfjh6IRGpuZB09zaKgEnHDEGDIDROqwDQWQk +15BvbMnBRwTKGVjmx/U0bM2aT06/JgkTZqET0daQizxN1yX2QfE2OKfCTptCOzSXHQm 8F33Phsm8uZC5dtQ6QaZOOI+qttgvvBCXqBRs1XtRvgwRNSE29M5jkso51fiwRSNiAT2 YRtXqKHuzszE/7a1YJrxIzqzdkurYZk2v0HRB/hTbSeZxoxSoioejJmcErI4Ch58yZkC rMlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id; bh=ZOoMS8MzZRIAEeTvnIpiLXWB9R+0EvIxqRljgmv4xe0=; b=bCEW+owCh/U+Ort+R7B59FClA0urHYd/C9pphYzMEpAPM8d8IigWad414G2v8rQWOj aDJVphtyOloKoTDDbMmYaxRf+6WHQuaj2CaLwGSak98NKZOw+cb3SEebtJPgoP23ZFeU oXWVGyfDMd2zNgWaD4bQyELaGz2HfovA7kLbMKpD3AwWzglz2qB+xGkHh8/zjbEy+Nvg 33FRMUtjJPQuwOHgechAnwA/iZlH/+B2/6WkC55E8Km5gqgVX1FFP3XdEjRoV0adLr65 Rq9NFShZ6pw1l5v6s5LO3aGZN/NPBcTmMU3CGTzmSxgh16UsnFZ4N72oTBS/hlhn/+Qz 0T+w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by gmr-mx.google.com with ESMTPS id r19si1249497eja.1.2020.06.26.01.13.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 01:13:39 -0700 (PDT) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of hws@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 49tV5G612rz1qs3Y; Fri, 26 Jun 2020 10:13:38 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 49tV5G5cYLz1qw73; Fri, 26 Jun 2020 10:13:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id L9tgwTOXLdJs; Fri, 26 Jun 2020 10:13:36 +0200 (CEST) X-Auth-Info: gKxMG2kyaGZK4fWOnLgbdsR9L6IJEvNZzKJx7GudalQ= Received: from maia.denx.de (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 26 Jun 2020 10:13:36 +0200 (CEST) Message-ID: Subject: Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing From: Harald Seiler To: Henning Schild Cc: Jan Kiszka , isar-users@googlegroups.com, Claudius Heine Date: Fri, 26 Jun 2020 10:13:36 +0200 In-Reply-To: <20200625212715.692fda49@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> <20200625212715.692fda49@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUID: E4VU4qdq37cP Hello Henning, On Thu, 2020-06-25 at 21:27 +0200, Henning Schild wrote: > 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. It does not. The reason /etc/os-release and the initramfs become related here is because the IMAGE_UUID from the rootfs needs to be added into the initramfs so it can later identify the rootfs it belongs to (when multiple copies exist). This is done by a separate initramfs hook installed as a package. > > 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? No, as described above, this is only necessary for IMAGE_UUID because there, a hook copies the IMAGE_UUID into the initramfs. The rest of /etc/os-release is irrelevant for initrd (AFAIK). > 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. I don't know what the plan is; whether IMAGE_UUID should be upstreamed at some point. Jan, you're probably the person to ask here? From my side, I think this would be a useful feature to have. > 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. In the other thread, Claudius has shed some light on the design decisions that let to this. But let's keep that discussion over there. > > > > 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! If you have a better approach than what I came up with, please do tell! I decided on postprocessing for a few reasons: - The IMAGE_UUID is an 'image feature' as in, the image recipe should decide what its ID is (an image inheriting `image_uuid` can set the ID string). So pushing that into a package is difficult. - As this only adds a value to /etc/os-release instead of deploying the whole file, a package approach would need to work via postinst which seems like a hack to me. - The previous approach from Quirin was to add a separate task for adding the UUID. This task can then be placed in the dependency chain where I have now moved the postprocessing but this feels like duplicated work when a postprocessing task exists as a feature already. -- Harald DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de