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

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

On 29.06.20 11:04, Claudius Heine wrote:
> 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.

If you can avoid installing, you do not need to remove things again for 
shrinking. That's what I meant here. Obviously, you can't avoid apt or 
dpkg in the first place, so that shrinking pattern would remain different.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux