Problem using Auto Install feature of dietpi.txt

With AUTO_SETUP_AUTOMATED=1 and the CONFIG_SERIAL_CONSOLE_ENABLE=0 the auto install finishes without error. So at this point I am guessing it is to do with a combination of settings I have changed in the dietpi.txt.

I will try again using my original changes I made to dietpi.txt and report back what it says on the screen when I exit the error.

I am ok with the error as I know how to get around it I can just leave the CONFIG_SERIAL_CONSOLE_ENABLE=1 alone and not change it and then disable the console once DietPi has installed. I just thought I would try and track down why it was doing so.

Ok here is what gets displayed on the screen in order:

[FAILED] File does not exist or cannot be written to by current user

Please verify the existence of the file $3

Retry with proper permissions or apply the setting manually:

I then can hit OK as that is the only option to this message and then the following message appears:

 [FAILED] Unknown install state/First run setup failed on another screen (PID=911).

You can <Take over> the error handling on this screen and kill the other DietPi-Login session.
Else you can finish the error handling on the other DietPi-Login session and <Retry> the login script on this session afterwards.
                             <Take over>                                     <Retry>

If I hit retry it just takes me back to the first error screen to which I can hit OK again and end up back on the second error screen. So I choose Take over instead of retry and get the folllowing:

/boot/dietpi/dietpi-login: line 116: kill: (911) - Operation not permitted
rm: remove write-protected regular file '/tmp/'?

It is at this point I am doing a ctrl-c and exiting.

Pretty strange. The first run setup inherently can only run as root, still out states to not being able to write to dietpi.txt to disable automation after the prior failure. This alone should be sure to filesystem error and R/O remount. But then it fails with the same error on the flag file, which is in tmpfs, for which I have no explanation, aside of that the /tmp mount was lost competely:

df /tmp

The missing permissions to kill the first run setup process on main screen is strange for the same reason.

It’s really as if the login wasn’t done with root user. But in this case you shouldn’t see any first run setup step in the first place but a related info that login needs to be done as root.

Ah no, the root check is done after the failure check. We need to change this.

So then the issue really is that you do not login as root, I suppose.

1 Like

Nice you found it? I am not going super crazy? I was starting to think it must be me as no one else is having this problem. Phew… So glad you seem to have found the problem?

I have written the DietPi image about 10 million times to my SD Card but it is all worth it if you have located an issue. :laughing:

But as said, the issue occurs since you do not login as root user on the second screen when the setup failed on the first screen.

And we still do not know why the setup failed on the first screen in the first place. For this we’d need some logs from before the error prompt. When you exit to shell, you should be able to find logs on the screen and/or in /var/tmp/dietpi/logs/dietpi-firstrun-setup.log.

Here they are, added .txt to the file name so I could upload them on the forum:

dietpi-firstboot.log.txt (8.5 KB)
dietpi-ramlog.log.txt (227 Bytes)
fs_partition_resize.log.txt (1.0 KB)

ok I adjusted our forum settings to allow .log files as well


There is no /var/tmp/dietpi/logs/dietpi-firstrun-setup.log? Then dietpi-software didn’t run yet. Since there are no errors in firstboot.log, I guess dietpi-update failed, e.g. because of a network connection issue. But this would need to be seen on screen.

There is no /var/tmp/dietpi/logs/dietpi-firstrun-setup.log so maybe it is failing to update?
There is a /tmp/ file though,

I am using my other RaspberryPi 3 ( as the DNS server that has PiHole and Unbound installed. Maybe it is too slow?

I have set a static IP within the dietpi.txt so it should not have to wait to be allocated one.

I do not understand why it works if I do not set the CONFIG_SERIAL_CONSOLE_ENABLE to 0 if it is the updates that are causing it to fail.

The Raspberry Pi 4 is on the network ok after the failed install as I am using SSH to connect to it.

I have just pinged google from the Raspberry Pi 4 the one that is failing.

/boot/dietpi/dietpi-login: line 116: kill: (914) - Operation not permitted                                                         
rm: remove write-protected regular file '/tmp/'? ^Cdietpi@RaspberryPi-4:~$ cd /var/tmp/dietpi/logs/
dietpi@RaspberryPi-4:/var/tmp/dietpi/logs$ ls -l -a                                                                                
total 28                                                                                                                           
drwxr-xr-x 2 root root 4096 Nov 20 20:52 .                                                                                         
drwxr-xr-x 3 root root 4096 Nov 20 20:39 ..                                                                                        
-rw-r--r-- 1 root root 8720 Nov 20 20:52 dietpi-firstboot.log                                                                      
-rw-r--r-- 1 root root  227 Nov 20 20:52 dietpi-ramlog.log                                                                         
-rw-r--r-- 1 root root 1074 Nov 20 20:52 fs_partition_resize.log                                                                   
dietpi@RaspberryPi-4:/var/tmp/dietpi/logs$ cd /tmp                                                                                 
dietpi@RaspberryPi-4:/tmp$ ls -l -a                                                                                                
total 12                                                                                                                           
drwxrwxrwt  8 root root  200 Nov 20 20:52 .                                                                                        
drwxr-xr-x 18 root root 4096 Nov 20 20:52 ..                                                                                       
drwxrwxrwt  2 root root   40 Nov 20 20:52 .ICE-unix                                                                                
drwxrwxrwt  2 root root   40 Nov 20 20:52 .Test-unix                                                                               
drwxrwxrwt  2 root root   40 Nov 20 20:52 .X11-unix                                                                                
drwxrwxrwt  2 root root   40 Nov 20 20:52 .XIM-unix                                                                                
-rw-r--r--  1 root root    4 Nov 20 20:52                                                         
-rw-r--r--  1 root root    4 Nov 20 20:52 .dietpi-login_firstrun_setup_err                                                         
drwxrwxrwt  2 root root   40 Nov 20 20:52 .font-unix                                                                               
drwx------  3 root root   60 Nov 20 20:52 systemd-private-3e4868ccee9d438e9ee6d134cbe0328e-systemd-timesyncd.service-sGInOh        
dietpi@RaspberryPi-4:/tmp$ ping                                                                                       
PING ( 56(84) bytes of data.                                                                          
64 bytes from ( icmp_seq=1 ttl=119 time=10.7 ms                                          
64 bytes from ( icmp_seq=2 ttl=119 time=10.8 ms                                          
--- ping statistics ---                                                                                               
2 packets transmitted, 2 received, 0% packet loss, time 1000ms                                                                     
rtt min/avg/max/mdev = 10.663/10.742/10.821/0.079 ms                                                                               

I have also tried doing a manual update:

dietpi@RaspberryPi-4:/tmp$ sudo apt update
Get:1 bullseye InRelease [116 kB]
Get:2 bullseye-updates InRelease [44.1 kB]
Get:3 bullseye-security InRelease [48.4 kB]
Get:4 bullseye-backports InRelease [49.0 kB]
Get:5 bullseye InRelease [23.6 kB]
Get:6 bullseye/non-free arm64 Packages [72.9 kB]
Get:7 bullseye/main arm64 Packages [8071 kB]
Get:8 bullseye/contrib arm64 Packages [41.0 kB]
Get:9 bullseye/main arm64 Packages [302 kB]
Get:10 bullseye-updates/main arm64 Packages [12.0 kB]
Get:11 bullseye-security/main arm64 Packages [203 kB]
Get:12 bullseye-backports/main arm64 Packages [361 kB]
Get:13 bullseye-backports/contrib arm64 Packages [3840 B]
Get:14 bullseye-backports/non-free arm64 Packages [9864 B]
Fetched 9358 kB in 9s (1041 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

for the first boot, you should login using root user. Don’t use user dietpi for first initial boot process.

Ah ok is this why it is failing? As I thought it would not matter because of this setting AUTO_SETUP_AUTOSTART_LOGIN_USER=root.

Anyway I have given up now with dietpi.txt auto set up and decided to just install DietPi manually.

Thank you Joulinar and Michalng for the help and time in trying to track down why it was failing though.

There is a misunderstanding on this setting. This user is not used for the first boot process. The user will become effective for automatic logins (if enabled) on 2nd boot, after firstrun update and installs have been done.

As already stated above. For an interactive automated setup, no login is needed at all. Just set AUTO_SETUP_AUTOMATED=1 an wait some minutes. This should complete the whole install process without user interaction.

I am so confused as I thought that is what I was doing.

I had set AUTO_SETUP_AUTOMATED=1 and left the AUTO_SETUP_AUTOSTART_LOGIN_USER=root as the default root.

I was then just logging in using the ‘dietpi’ user to check on how the auto setup was going. If I had not changed the CONFIG_SERIAL_CONSOLE_ENABLE to 0 then I would get a looping message telling me auto setup was running on another user (screen) and it would check every 5 seconds if it had finished. Once it had it would drop me into a working console as the dietpi user. If I had changed the CONFIG_SERIAL_CONSOLE_ENABLE setting to 0 then when I logged in as the dietpi user I would just be shown a failed setup message.

best would be to configure your auto install setup, connect a screen and boot of the SD card. Usually, you should see the install process running. Does it fail as well if you are not going to login?

It aeems to fail somewhere where no logs are saved to a file about it. So without seeing the process on the main screen, we won’t know where/why it failed.

I just tried again this time I kept everything the same except I did not choose to do a headless install. I tried to catch a video on the monitor I connected but failed as I forgot to plug in the screen. It gets to the error so quick that it is impossible to see what it says on the screen before it clears it and displays the error message.

The error message it shows on the monitor is the one in this post: Problem using Auto Install feature of dietpi.txt - #12 by ISquishWorms

I hit enter key on this screen and it carried on installing and managed to install correctly. So if I watch on a monitor and connect a keyboard I can hit enter to carry on with install which then manages to complete ok.

You should be able to see the console output when you do not rerun the first run setup but exit to shell instead. However, if a simple rerun works, it is very likely a network issue, resp. that it takes a little longer than ifup before the connection test succeeds.

There are these dietpi.txt settings to give it some more time and/or attempts before failing:

# Connection timeout in seconds for G_CHECK_NET and G_CHECK_URL. Increase if you have a "flaky" connection or slow DNS resolver.
# - Set this to "0" to allow unlimited time, however this is not recommended to avoid unlimited hanging background scripts, e.g. daily DietPi update check.
# - A negative or non-integer value will result in the default of 10 seconds.
# Connection attempts with above timeout each, before G_CHECK_NET and G_CHECK_URL give up and prompt an error.
# - Any value below "1" or a non-integer value will result in the default of 2 attempts.