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

["'Heinisch, Alexander' via isar-users" <isar-users@googlegroups.com>]

> > ## Identified Problems
> >
> > 1.  **Problem**: The installer script has to provide an unattended mode.
> >
> >     **Possible Solution**: Add setting for unattended mode either via
> > well known config file or via kernel cmdline.
> >
> > 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)
>
> Yes, sounds like swupdate and friends...
>
> Nevertheless, I find the idea of using swupdate rather than the current script not that bad at all.
> I has some nice side effects. For example any custom pre/post processing could be simply done by writing scripts and add them to the swu container. So there would be no need to customize the current update script. That decouples downstream customizations very nicely...

Yes, this also adds the benefit of having utilities for e.g. disk-encryption (reencryption or changing keys) available during updates, reducing downtime.
(Plus in addition we don't have to ship the overhead of the generated full wic image.)

Currently the installer script has some interactive mode (dialog). In the initial proposal, we'd planned to support interactive mode alongside unattended mode depending on config or kernel cmdline of the installer.
I'm not sure how this would work with swupdate! It remains open, if the use case for such interactive mode is strong enough to have two solutions in place? (e.g. current installer + swupdate based installer) -> I would highly prefer only having one 😊


>
> In conjunction with wfx [1] as update server I could imagine that very complex setups were possible.
>
> I'm not sure wether or not isar is the right place for this feature. This could potentially fit better into isar-cip-core which implements these type common patterns?!

When switching to swupdate, cip-core is probably the right place (since the build infra is already in place).
When using a custom script, isar is probably the better place, to support a wider range of downstream projects.

>
>
> [1] https://github.com/siemens/wfx
>
>

Absolutely!

>
>
> >
> > 3.  **Problem**: Since pxe transferrs only the kernel and the
> > initramfs via TFTP (rather slow) When using pxe we have to provide the rootfs of the installer via nfs.
>
> You could checkout iPXE. It uses http/https for downloading.

Currently, I was going for PXE only, because of higher compatibility.
In case of iPXE, I'd chainload iPXE boot rom via PXE boot.
Although, ipxe compatibility is pretty widespread (https://ipxe.org/appnote/hardware_drivers), I could not find the NIC we are currently using (Intel I225-V 2,5 GBIT Ethernet).
Maybe I will test that someday 😊

>
> >
> >     **Possible Solution**: Having an online installer downloading the
> > target images from some external source, enables us to put all
> > installer logic in the installers initramfs. Thus, no need for an installer-rootfs.
> Using an initramfs may be fine, but as soon as the installer needs internet you will encounter issues due to missing support of different libraries. In other words, the more features we support the more needs to be added into the initramfs and installation into initramfs can be very cumbersome and time consuming (files have to be installed directly since no package-manager available).

Using a rootfs simplifies a lot of things! I'd also prefer using a package manger 😊
Still, when using the installer in the field (e.g. from an usb stick) having all inside an initramfs (except for the signed image) could simplify integrity checking.
For the initial implementation I'd go with the rootfs, and extend on this, once the requirement emerges.

-- 
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/AM7PR10MB3320406577F5B58F8DEF8E53868C2%40AM7PR10MB3320.EURPRD10.PROD.OUTLOOK.COM.