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

[Claudius Heine <ch@denx.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3141 bytes --]

Hi Jan,

On 26/06/2020 11.12, Jan Kiszka wrote:
>>>>> 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.
>>>
>>> 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.
>>
>> Its been a while when I implemented this, but I also thought of the
>> scenario where someone would like to 'minimize' a image via the root fs
>> postprocessing by deleting everything that is not needed, and that could
>> possible include the kernel + initramfs, if those are stored somewhere
>> else outside the root file system. So the idea was, IIRC, to move the
>> kernel and initrd to the deploy dir, out of harms way, before
>> postprocessing does its rootfs manipulation.
>>
>> So by ordering the copy_boot_files behind the root fs post processing,
>> you might break other layers that rely on this ordering and have such
>> 'minimization' procedures, that remove the kernel package and specific
>> files.
>>
>> We don't have such 'minimization' stuff in upstream isar, since it
>> pretty much breaks apt and dpkg, but if you do image based update, you
>> might not care.
> 
> I think the problem with this pattern is elsewhere: We should not
> install stuff on the rootfs in the first place that shall not end up in
> the rootfs.

Not sure if I understand you correctly. Do you mean that minimization in
the rootfs postprocess should not be done and instead the things that
get removed there should just not be installed?

To be concrete, one thing that might be removed is 'apt' and 'dpkg'
itself. The only way how you can setup a root file system without it is
if you would install it using a package management from outside the root
file system.

While this would be the cleanest approach, and might even be supported
(See RootDir in apt.conf(5)), that would mean pretty massive changes to
Isar.

> That this copy_boot_files thing depends on the installation
> on the rootfs is actually a bug. It should use the chroot for its work,
> like the imager does (for the bootloader e.g.).

Right, copy_boot_files is in need for some rethinking.

regards,
Claudius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]