From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a1c:7d85:: with SMTP id y127mr2161588wmc.181.1593159580608; Fri, 26 Jun 2020 01:19:40 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:f58d:: with SMTP id f13ls59783wro.1.gmail; Fri, 26 Jun 2020 01:19:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHIxrW/1WH6mQ2uA+ek1KKEPkUwMzIckUfLVxaetiuckpeGtZk7lnR2KOQoAfL2UCMkbXq X-Received: by 2002:a5d:6603:: with SMTP id n3mr2527806wru.142.1593159580003; Fri, 26 Jun 2020 01:19:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593159579; cv=none; d=google.com; s=arc-20160816; b=dRS/Xq/5sc3jCzS33BfJARHa6vLgD3wUG4jakFHAHfOQVZWMvvEpMbYCCS19h4Uql+ e0y70AeIlLay4Yg+rKZg/Z8MmDGPlcqVurUOML8OANp8+pA9CdQF2D9cy0Htcl1exnTo dtHnp6Ygjzwc1g2+mX7LZm1qLsu4ImI+z/PawL9ydUeXn5y4GvLakS6ip+R1hIHrf2NK WGgLeuA+nKfgmQKjZKYQxF2OzZTK0wqbyP6HIP2Lmu/kxejhMc8affjkH2SYcVR+CGF4 tz0yClOEYPLreJ7EKR/I3SLCtDVoRRJvPOcI/JFoqzBb1KcfbYtHYO5H8tCS/d3kw1+4 uXVw== 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=IYCilGxphwpuBmE5LrFu1dEI1oJSkH8cyWF6d8TYNXE=; b=iuPC0mufGj30IGkdIc6kzpAnKHh1uTSEDMBtNFawz6LLv6s5tIDQdaen+2K/gXWGvo n3+c9yzuYcw25wYToOGmLSz0xvgLDxtRKkw6suOoFtZsjg741WfH7LRDWdbhwjjwrvLn PPOrGO6V/hk30tsgfVKSqYBO5kLp/NFOe3Jb0mJEHkpMLqetHY2RNRZsY5Eldg1mHgAF trJDx2mnIPCIaj0K9KQWMlW0pwKDFQf2xQ7UEpLbRW2FmtJx8CWha2X9+rzC3U/xXvOq wxOlhLLpLxXtUjVcN5ox5zQ+k3EG5E6BYMssHwUdYYawU5jOEjMnb5GDmlNiVDcHCiio 930Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id g141si669017wmg.0.2020.06.26.01.19.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 01:19:39 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 05Q8JchF013106 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Jun 2020 10:19:38 +0200 Received: from [167.87.241.222] ([167.87.241.222]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05Q8Jbbb014237; Fri, 26 Jun 2020 10:19:37 +0200 Subject: Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing To: Harald Seiler , Henning Schild Cc: isar-users@googlegroups.com, Claudius Heine 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> From: Jan Kiszka Message-ID: Date: Fri, 26 Jun 2020 10:19:37 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: /yhnZ6AOsqCk On 26.06.20 10:13, Harald Seiler wrote: > 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. That class is currently coupled to the use case of A/B partition selection via initramfs for the purpose of atomic system update. If we see use cases beyond, it would be straightforward to upstream. For the time being, the update integration will be evolved in isar-cip-core. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux