Amadjan, I am not sure what you mean. Are you also having issues with the dietpi.txt file or is yours working as intended?
If you like to get support, same more information would be great. What exactly is not working. Some details on your setup like SBC aso.
Good to know, thought I was going crazy. Well I have been crazy since I was born but still… 
Yes correct, we tried to make it clearer which image to use for which RPI device. There was to many confusions on the different versions. ARMv6/7/8 
ok I did a test with my RPi4B and automatic install was working perfectly fine without issues.
- download image https://dietpi.com/downloads/images/DietPi_RPi-ARMv8-Bullseye.7z
- write SD card suing Rufus 3.20 on a Win11 box
- adjust three values inside
dietpi.txt
AUTO_SETUP_NET_HOSTNAME=DietPi4-demo
AUTO_SETUP_AUTOMATED=1
AUTO_SETUP_GLOBAL_PASSWORD=xxxxxxxxxx
- boot RPI4B and watch install process via attached HDMI screen
- done
1 Like
Thank you for taking the time to test it.
I do not know then why it does not work here. I might try a couple more times changing different parameters within ‘dietpi.txt’ to try and locate which of them is making it fail here. If I can’t track it down I will ust have to skip using the auto method and resort back to doing the initial set up via ssh.
Oh and yeah separating the images out for various RaspberryPi’s def makes things easier when picking the right file.
just go with the settings I used. This way we could check on your end how it behaves compare to my system
And if possible, try different SD cards or simple another USB pen stick. Your RPi4 should be able to boot of USB ootb. Which I would recommend anyway 
Changing just the options you changed along with adding my static IP settings worked.
At first when I tried to log in I got a message that auto setup was running on another screen which kept repeating every 5 seconds and after a bit it finished and dropped me to the console. No errors.
Hmm what options to try changing next?
Why would you recommend booting from a USB stick? I ask because I have read that USB sticks can actually be slower than SD Cards, depending on various factors and situations. I do not really have a free USB stick to use either.
What I would like to do is purchase a good SSD drive of a resonable size and have it boot from that but I am not sure which drive and adapter to buy and everytime I look into it I just get confused as I read conflicting reviews. I sort of like the idea of getting a Crucial SSD but again which one? Maybe one day I can make a decision.
SD cards are not designed to run 24/7 and they have a trend to fail on constant r/w operation like NextCloud would do. Using a USB3 pen stick should be faster compared to SD card. SD cards are not that reliable. As an alternative you could look into RPI eMMC module RaspiKey. It’s not an official RPi module and quite expensive but working fine on my test system.
At least this are our expectance.
Of course, SSD is the best option for performance. If you get one, keep in mind to have it self powered. USB ports of RPi4 are not designed to power larger HDD/SDD. We have seen a couple of issues in past if external drives are not having an own PSU. It might gonna work but no garantee.
I have found the problem.
I went through each setting one at a time writting a new copy of the image each attempt. After what feels like 5 million SD card writes 
here is the line that seems to make my auto install using the ‘dietpi.txt’ file fail.
# Serial Console: Set to 0 if you do not require serial console.
CONFIG_SERIAL_CONSOLE_ENABLE=0
As soon as I changed this from a 1 to a 0 the auto install fails.
let me try to replicate. Thx for your input so far.
hmm for me this is working fine, no issues during first automatic boot 
[ SUB1 ] DietPi-Set_hardware > serialconsole (disable)
[ INFO ] DietPi-Set_hardware | Disabling serial-getty on: /dev/serial0
[ OK ] DietPi-Set_hardware | systemctl unmask serial-getty@serial0
[ OK ] DietPi-Set_hardware | systemctl disable --now serial-getty@serial0
[ OK ] serialconsole disable | Completed
I just tried again and same result if I leave it set to 1 then it works if I change it to 0 then fails.
Maybe it is a combination of my settings and that line or maybe it is because I have a really early Raspberry Pi 4 as I purchased it as soon as it was released?
I have to go do some chores now but can test more later, that is if there is anything left for me to test.
Here are the two files I am using which only contain that one difference, one works the other fails.
dietpi_not_working.txt (16.1 KB)
dietpi_works.txt (16.1 KB)
Keep in mind I am also setting an SSH key which I have removed.
How does it behaves if you set CONFIG_SERIAL_CONSOLE_ENABLE=0 only, without other changes?
With just CONFIG_SERIAL_CONSOLE_ENABLE=0 set it seems to work, although it does stop and complain along the lines of the user not having access to dietpi.txt which I just hit ok and then login using sudo su and the install then continues as normal.
Hmm maybe it is because I am adding this line dtoverlay=gpio-fan,gpiopin=14,temp=60000 for fan control to config.txt and also choosing to disable the serial console? Does this sound like it could cause a problem? It did not cause a problem during this test though as I still added the line to the config.txt.
When it does fail it is like it happens very early on prior to any auto updates or anything, the fail screen appears almost straight away.
On an automatic install, no user login is required. Can you describe the issue with the user? Which one you used?
Hmm, probably for some reason one of the steps to disable the serial console fails. Does it work to disable it after you finished first run setup?
/boot/dietpi/func/dietpi-set_hardware serialconsole 0
But this does not explain why taking over the failed first run setup fails with the read-only file error, especially because it is a file in tmpfs with isn’t affected by automatic R/O remount of the rootfs, e.g. in case of critical filesystem errors .
An output of dmesg -l emerg,alert,crit,err would be interesting when you run into this error. Also, when you exit the failed first run setup on main screen, what are the last lines on the screen?
Ah the serial console is disabled during early firstboot script already without error. Then I have no idea how it could have an effect on the first run setup done after (automatic) login…
This was not an Auto setup as I only chanaged that one serial console setting, I will try again this time using AUTO_SETUP_AUTOMATED=1 and the CONFIG_SERIAL_CONSOLE_ENABLE=0 setting.