[WIP][TEST] Image customization

[BennySt]

Hi there,

 

while the customize-image.sh got some attention lately because of OMV integration, I've started a try to enhance the customization process.

At the moment any changes to the script are valid for the whole buildenv. That might be good when building just one image but all over I think thats not a good situation, especially for automated building or with more then one customization.

 

I startet to define a $CUSTOM Buildvar and redefined the script locations, starting with the following changes:

- delete customize-image.sh an overlay dir

- placed it under config/customizations with following layout

   *-chroot.sh, *-host.sh, *-overlay dir

- changed the buildenv script to show a new dialog when $CUSTOM is not set or set to 'none'

- append $CUSTOM to .img name

 

At the moment I do some testings but it should work already.

Want to share this for some feedback, thoughts and opinions

The code is her: https://github.com/Diggen85/build/tree/customize-image

 

 

[zador.blood.stained]

Breaking existing costomization setup is not a good idea.

In addition current customize-image.sh is flexible enough - you can execute other scripts and transfer other files based on build variables. But passing extra variables to that script and changing resulting image name may be a good enhancement.

[tkaiser]

I second Zador's opinion. Backwards compatibility is mandatory. But a few more variables need to be exported to the script (since it's not 'costly' I would suggest exporting as much as possible). ATM I run a rather stupid kernel detection method for example.

[BennySt]

My changes are not gone break much. existing scripts will work in the same favour as before, just renamed/changed location.

In my opinion it is just flexible if you have not more than one customization, like atm OMV. When adding in the future e.g own/nextcloud it will become unflexible

But I understand your concerns.

Putting all logic to customize-image.sh may be also a way. This would mean no dialog options but flexibility while retain full backward compatibility.

 

Adding extra variables to customize-image.sh should be no big problem. Will have a look a it.

 

 

[zador.blood.stained]

OMV customization is WIP and is more a proof-of-concept. I am in favor of moving it into a separate script to keep the main sustomize-image.sh template as clean and easy to understand as possible.

[BennySt]

I know is WIP & POC. I was the one who posted the initial customized-image.sh and tkaiser improved it a lot and take a lot of effort on this.

If you are in favor to separate it, tell me more about it and I will help you, if you want.

[tkaiser]

My 2 cents: The OMV addition is really just a POC and we should use it to discuss use cases like this (since looking around it feels really weird that the wheel gets re-invented every few hours again, so many projects could easily use Armbian's build system as a stable base).

 

The OMV installation routine should be removed from the customize-image.sh template and we should try to make such 'add-ons' ready for build-all.sh (eg. define CUSTOMIZE=OMV prior to calling build-all.sh)

 

Based on my experiences this is the wrong approach anyway since we optimized Armbian's build system that much that after the first run the base image is built within 5 minutes and the lousy OMV installation routine takes another 20 minutes **for every build** but that's part of the journey.

 

We discussed optimizing build-all process a year ago and maybe that's something to look into again if some more of these 'add-ons' should be supported (since it's plain stupid to build let's say 10 sun7i OS images that way which will take 250 minutes in total instead of building one generic sun7i image in 5 minutes, adding OMV in 20 minutes and creating all the individual OS images in 3 seconds later -- that's the btrfs magic we were talking about one year ago)

[zador.blood.stained]

11 hours ago, tkaiser said:

that's the btrfs magic we were talking about one year ago

Even though it's a little bit off-topic here - using overlayfs may be a good alternative, which doesn't depend on build machine filesystem type.