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

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

On 13.10.20 12:26, Harald Seiler wrote:
> Hi Jan,
> 
> On Tue, 2020-10-13 at 12:19 +0200, Jan Kiszka wrote:
>> On 25.06.20 17:33, Harald Seiler wrote:
>>> In some cases, postprocessing might trigger an update of the initramfs
>>> which would not appear in the deployed version.  Fix this by running
>>> copy_boot_files only after all postprocessing completed.
>>>
>>> Signed-off-by: Harald Seiler <hws@denx.de>
>>> ---
>>>  meta/classes/image.bbclass | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>>> index 0150f2718573..21d634a8f34f 100644
>>> --- a/meta/classes/image.bbclass
>>> +++ b/meta/classes/image.bbclass
>>> @@ -153,7 +153,7 @@ do_copy_boot_files() {
>>>          cp -f "$dtb" "${DEPLOY_DIR_IMAGE}/"
>>>      done
>>>  }
>>> -addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install
>>> +addtask copy_boot_files before do_rootfs after do_rootfs_postprocess
>>>  
>>>  python do_image_tools() {
>>>      """Virtual task"""
>>>
>>
>> There was a lengthy discussion after this, but I don't think the
>> conclusion was to hold back this patch, right? We are using it at least
>> in one case internally, so this should likely go in now.
> 
> At least from my side we can drop this.  In the project where I needed
> this it is now gone, because I switched to the alternate initramfs
> mechanism over there.

Seems that this change in the downstream project didn't hit its master yet.

> 
> Also, the arguments where this patch might break downstream use-cases do
> hold some truth so I'd rather err on the side of caution and not go this
> route.
> 

OK.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux