Do you use any preconfiguration files / preseed to automate debian install prior to run PREP_SYSTEM_FOR_DIETPI.sh ?
Not really, also since it is hardly possible due to the vast differences between devices. As said we usually flash a ready-to-use image as a basis to run PREP_SYSTEM_FOR_DIETPI.sh on.
On x86 there are possibilities to automate the Debian installer: https://www.debian.org/releases/stable/amd64/apbs01.html.en#preseed-methods
But the effort to add all required variables and generate the adjusted installer IMO is just too hight for those few images. Every device needs different values and in case the installer changes (upstream) we would need to verify/adjust all those again. So I currently prefer to go through it manually, which does not take more then 5 minutes anyway.
Yeah so as long as we don’t install the base system from scratch via kernel + bootloader sources IMO there is not much point/possibility to automate base image creation.
It’s not much for automation but reproducibility.
Maybe ill endup doing it but it feel wrong to me to take the official dietpi image, run the first run installer, then remove the features that just been installed.
The path kinda start to getting long :
Debian publish → raspbian recompile and add a layer of crap → dietpi strip it → dietpi add his layer of features → Lysmarine will strip a part of it → lysmarine will add his huge layer of software;
So I think the cleanest approach for me would be to sort what I need and don’t inside PREP_SYSTEM_FOR_DIETPI.sh ,
But it’s hard to hack in PREP_SYSTEM_FOR_DIETPI.sh if I IDK how to reproduce the base images.
… Also i might be wrong with all of this. ¯_(ツ)_/¯
… ohhhhh Unless PREP_SYSTEM_FOR_DIETPI.sh whipe Dietpi scripts from a Dietpi img Before installing Dietpi scripts.
[Insert dwag meme gif ]
So I could take an official Dietpi image And run A hacked / WIP / testing PREP_SYSTEM_FOR_DIETPI.sh script on it as if it’s was the upstream image without caring that it been run on this image before.
Is that how PREP_SYSTEM_FOR_DIETPI.sh is designed ?
PREP_SYSTEM_FOR_DIETPI.sh will indeed remove old DietPi code in case, before installing the new one. Just in case we indeed we use an older DietPi image as basis to avoid having perhaps deprecated files in place. So yeah you could redo it’s code to your needs and use a DietPi image as basis.
Since PREP_SYSTEM_FOR_DIETPI.sh is already a merge of two prior scripts (we did even more manually in the past), it is still a bid messy. So yeah I can imagine that it is hard for you to understand all that is done, especially as there is so much depending on the SBC model, distro version, architecture etc. Feel free ask questions about this, at best on GitHub since I will faster recognize it there 
.
I planned to clean and sort the code by times, but there is simply too much to do with the deployed scripts, software install code and such currently.
And you are totally right IMO that the great benefit of having all steps (automated) in scripts is to have them documented and reviewable somewhere and allow to have things 100% reproduceable. E.g. I made a start to document image creation steps in the Wiki, e.g. here for VirtualBox images: https://github.com/MichaIng/DietPi/wiki/How-to-create-a-DietPi-image-for-VirtualBox
So much to do, so little ressources, I feel you. That’s kinda the curse of all FOSS project.
— PRESED USAGE.
Preseed are a configuration file that can be use during the install process of a debian.
It can be provided to the debian installer in 2 ways.
Add the config file to the iso image prior to be used.
I did not explored this way yet as it’s more complicated and harder to do manualy then not using it at all.
Provide an URL during the install process
The file used in this example is a default file found on the internet and not yet adapted to dietpi needs
It can be found here : https://raw.githubusercontent.com/FredericGuilbault/lysmarine-build-tool/master/debianPreseed.cfg
As I understand, what is not defined in the preseed file will be asked. So things that are architecture dependent could be let for manual input.
FredericGuilbault
Many thanks for this. The URL method would be anyway more reasonable here, as we would anyway have this config stored on GitHub.
I will go through it by times, but as mentioned somewhere else, going manually through the steps is not too time consuming on the comparable fast x86 machines where we can use the Debian installer. So it is more a way of documentation and to make things more reproducible for interested users/contributors like you, than a real speed-up/effort reduction.