DietPi-PREP | Allow non-interactive execution via environment variables

[FredericGuilbault]

Creating a feature request

Is your feature request related to a problem? Please describe:

when PREP_SYSTEM_FOR_DIETPI.sh is executed, it prompt for user input witch prevent the automation of the build process.

Describe the solution you'd like:

I have made change to the first 5 questions to support environment variables.
https://github.com/FredericGuilbault/DietPi/commit/95fddde83da22080c5351857e8561c7121f9cfdc
Im not sure about the naming convention and styling. So if you could review it before I continue that would be awesome.

I need this those changes to play nice with https://github.com/FredericGuilbault/lysmarine-build-tool

[MichaIng]

@FredericGuilbault
Good idea, I like it. I will implement it in a slightly different way so that the environment variables are checked for valid value and in case revert to user prompt.

[FredericGuilbault]

Just to avoid confusion (Cuz im good at being confused) In :

I will implement it

You mean you are going to do it and I don't have to do a pull request ?

[MichaIng]

@FredericGuilbault
Feel free to open a PR. Possibly I adjust it since as mentioned I would like to keep the entry validation checks and in case of invalid entry exit with error.

And yes otherwise I would implement this anyway, after v6.23 release.

[FredericGuilbault]

Good, Ill make a PR,

On an related topic, Im still trying to understand how dietpi is created, Do you have all those SBC at home?

And at each version you download the original operating systeme, put it on a SD card, physicaly put the card in the SBC , boot the machine, wget the PREP_SYSTEM_FOR_DIETPI.sh, run it, put back the sd card on your computer, make an .img out of it, upload the .img on your website ?

[MichaIng]

@FredericGuilbault
Exactly. @Fourdee (actual founder of DietPi) has all the SBCs. I only take care the RPi, x86_64 and virtual machine images.

We do not create new images on every DietPi release. Since DietPi updates itself (including all APT packages) on first boot, this is only required if critical changes to the base image have been done that cannot be patched (via APT). But if we create new images, then yeah this is how we do it.

There exist some thoughts about running the script via qemu + chroot: #1775
In combination with an image creation script (#2693) everything could be then be done in one run from a qemu capable environment. However since new images as mentioned come mostly with changed kernel/bootloader and such, I anyway prefer to run this on the actual device, so any possible bugs or obsolete configs and such can be solved.