Hello,
is it possible to force a first run setup on already running system?
Are all values defined in /boot/dietpi.txt (re)applied?
Can you provide a little more background information on what exactly you want to achieve with this?
I have running some dietpi-lxc containers on proxmox.
Sadly there is only a VM of dietpi available for proxmox.
So you have do the conversion step from VM to CT every time you like to install a new CT …
Because of this I decided to create a template from a running dietpi-lxc. Works so far, but I get all configuration like done before.
Sometimes this is not what I want.
I would like to have a CT, but just like a fresh dietpi installation…
Maybe there is a file or something else that indicates that the first run setup is done, and I just have to remove this file 
you would need to enable the first run service
systemctl enable dietpi-firstboot
adjust /boot/dietpi/.install_stage to -1
and maybe remove /boot/dietpi/.installed as well
Another idea would be to run the dietpi-installer on the system, shutdown, and create the template then. This would be cleanest, resetting it to the stage of a fresh image that was never booted.
To only rerun all first boot setup steps (also re-applying settings from dietpi.txt or dialogs), enabling the dietpi-firstboot is fine. Not even needed to change the .install_stage, since dietpi-firstboot sets it to 0 anyway, triggering first run update and setup prompts on next login. Does not hurt to leave /boot/dietpi/.installed in place then, to indicate installed software correctly, even if you installed something else, switched from Dropbear to OpenSSH or such.
Hello,
first of all, thank you for your support.
Enabling the firstboot service works fine so far.
But I get this error after reboot.
tune2fs: Datei oder Verzeichnis nicht gefunden while trying to open /dev/loop8
Couldn’t find valid filesystem superblock.
Looks like the firstboot process stops after this error….
is it possible to supress calling tune2fs in a lxc container ?
This is fixed for DietPi v9.18. v9.17 enabled image generation without ext4 journal, generating it on first boot after filesystem expansion. Since the journal is essential to protect against data loss on crashes etc, it is checked on first login. But containers usually have no access to the block devices, hence cannot create a journal and cannot really check whether one exists either … though maybe there is another way than using tune2fs 
.
However, v9.18 shows an info but allows you to continue the setup if the rootfs block device does not exist.
Workaround:
sudo sed -i 's/! tune2fs/tune2fs/' /boot/dietpI/dietpi-login
EDIT: Testing some ways to check for a journal within a container. Can you show the output of these commands please?
dmesg | grep "EXT4-fs (${G_ROOTFS_DEV#/dev/}): .* with [a-z]* data mode"
grep -E '^(journal_checksum|data=)' "/proc/fs/ext4/${G_ROOTFS_DEV#/dev/}/options"
Output of this is nothing …
dmesg | grep "EXT4-fs (${G_ROOTFS_DEV#/dev/}): .* with [a-z]* data mode"
I guess because dmesg ist not allowed
dmesg: read kernel buffer failed: Die Operation ist nicht erlaubt
but this works …
grep -E '^(journal_checksum|data=)' "/proc/fs/ext4/${G_ROOTFS_DEV#/dev/}/options"
journal_checksum
data=ordered