Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing

[Jan Kiszka <jan.kiszka@siemens.com>]

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" <henning.schild@siemens.com>:
>>
>>> Am Thu, 25 Jun 2020 20:43:07 +0200
>>> schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:
>>>
>>>> Am Thu, 25 Jun 2020 19:24:30 +0200
>>>> schrieb Harald Seiler <hws@denx.de>:
>>>>    
>>>>> 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