Re: [meta-isar] Proposal to improve initial device bootstrapping

["'Gylstorff Quirin' via isar-users" <isar-users@googlegroups.com>]

On 7/18/24 1:34 PM, Heinisch, Alexander (T CED SES-AT) wrote:
>>> 2.  **Problem**: When embedding the target image into the installer rootfs a rebuild of the installer image is required everytime we change the target image.
>>>
>>>       **Possible Solution**: Installer image could download target
>>> image from http/ftp/s3 server at runtime and install it from memory.
>>> (Therefore, we have to ensure enough memory is provided, or probably
>>> support some kind of streaming functionality)
>>
>> This sounds like what SWUpdate or rauc already provide. Which could be used to describe the system and also provide a installation state.
>>
>> Quirin
> 
> (I will focus on SWUpdate, since we already ship it in our target images.)
> 
> That means instead of deploying a wic image like now, we could ship
> e.g. SWUpdate and use an swu file to execute the tasks described?
> Therefore, a reuse of partitioning and image deployment from such utility
> was possible, putting the steps described for encryption,
> secure-boot deployment, aso. as post scripts.
> 
> Although, I see the value when it comes to image download/streaming
> and verification of such, I'm not sure if the gained value of having SWUpdate
> outweights the effort of shipping SWUpdate for an installer,
> compared to a relatively simple script.
> bmaptool, which is used right now to deploy the image, already supports
> downloads from http(s)://, ftp://, ssh:// and file:// sources, checksums
> and signature verification.

Signatures are pgp based so an additional effort to generate and 
maintain them.

> 
> + Reuse of existing logic (SWUpdate)
> - Harder (although not that hard at all) to understand compared to
>    (imo relatively) simple script logic
> - Build and ship additional component/dependency SWUpdate
> ~ Build additional image for swu
>    (probably that's done anyways if SWUpdate is in use for OS/Firmware updates,
>    but downstream projects could use other stacks like rauc, mender, ... already)
> + Same workflows for encryption / sb-enrollment could also be used on upgrades
> 
> What was the reason not to use SWUpdate for the current installer?

The initial use case of the current installer was to have a simple way 
to deploy test image onto the disk of a target device. This first 
implementation was using dd instead of bmaptool.


Quirin
> 
> BR Alexander

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/fe6a168e-7280-432f-bb35-017258da4de2%40siemens.com.