how to uninstall it safely? I didnt find any info in dietpi scripts and this forum too. Ty
Hello,
What do you mean by uninstall? If you mean software, there’s an Uninstall option in dietpi-software. If you want to remove DietPi itself from a Debian system that you used the prep script on, you can’t, as DietPi makes (basically) irreversible changes to your system.
It might be possible by reverting all steps done by PREP script. But it would be quite some manual effort to remove DietPi settings/tools and replace them with standard. I doubt it was done before. Would be easier to start with a new clean installation from the OS you like to run.
k so how to disable autoloading dietpi all components if uninstalling isnt possible?
Honestly I don’t understand where you like to go and what you are trying to achieve. If you are going to disable DietPi componets, your system will not start. Maybe you can give some more information on your goal.
This post is interesting, actually 
Is it any way to disable/remove all DietPi components - but still having a stable Raspberry Pi OS (I have a Raspberry Pi 4)?..
What if I want it for security (using the minimal DietPi image as a great base, but after the install&config of everything it’s needed - a removal of “postboot&preboot dietpi services” and so on would look quite nice actually )?..
Or simply to free some space?..
Or even to speed up quite more the boot process?.. (In the end, it will be a stable OS with overlayFS and it shouldn’t need updates or stuff, actually - and this might be the case for a lot of Raspberry Pi-es, actually, I guess, not just our case… )
Some system core features are provided by our boot scripts, like applying the CPU governor and starting up software services installed via dietpi-software. Of you really want to disable the boot scripts, you can do that via systemctl the regular way, but we won’t offer that as regular feature to break a lot of other features 
.
But we are about to minimise the tasks done by the boot scripts, in first iteration removing dietpi-boot (preboot and postboot will stay in first iteration) as it does not more than waiting for network and doing a time sync. The first is not really required anymore and the second can be offloaded into a dedicated service that does not delay boot and is optional depending on chosen time sync option.