[Solved] After upgrading DietPi, it wants to set up as it was fresh


i’m using an Intel mini PC with the UEFI image from GitHub, which boots with rEFInd.

It runs smoothly, but after doing the latest upgrade, to 6.20.6, every time I boot I need to Ctrl-C, because, if I don’t, I go directly into the first configuration wizard and I get stuck there.

What do I have to do to boot normally?

First screen I get (I tell it to cancel)

Second screen, to change the user password, I cancel.
I get here, and click on exit:

This is what I get:

And I get back here again:

Thank you very much,

Now I realize, after upgrading, my lighttpd and syncthing seem to be dead.

I can wake up “Syncthing” using:

service syncthing start

and it seems to work,
but after

service lighttpd start

I cannot go into /admin folder, where I have the Pi-Hole Admin Console.
I get:
503 - Service Not Available

I reboot, and see as lighttpd and syncthing are not running, how can I change it, to load them when computer starts?

Thank you!

It was php.

service php7.0-fpm start

I can get into Pi Hole Web Admin.

So, now, I have 26 services; when I reboot, I have 18.

Is this related to the “first boot” screens I get, maybe it doesn’t start all the DietPi Services I had configured?

Thank you,


When I type

dietpi-services restart

I get all the processes up.

I need you to know how to tell DietPi it’s yet configured, so the “first boot assistant” is not loaded.

I am having the same issue with Odroid C2

I hope somebody will help us,

It must be a service that is marked as “active”, and it must be disabled; when the “first boot assistant” is loaded, as you see, a lot of services are disabled.

The workaround is pressing Ctrl+C when the system boots, or when you go into it by SSH, and, after that, typing:

dietpi-services restart

But this is a workaround, not a solution.

Hi! Did you watch this thread?

Jep the issue should be fixed with v6.21. If you are still stuck in the loop, please cancel any dietpi-software prompt and do the following:

> /DietPi/dietpi/.update_stage
echo 1 > /DietPi/dietpi/.install_stage
dietpi-update 1

Thank you, I hadn’t seen it.

Thank you very much.

Now the issue is solved, at last! :smiley:


I’m still having this issue, though it may be my fault for a couple reasons. I have an older image, 6.14, and it’s been auto-updating to 6.x through a series of reboots just fine until I hit this issue. I had hoped this would resolve it for me, but I receive ‘No updates required’ and I’m running 6.21.1 by the time the updates end.

I host a script on GitHub which runs after boot using the URL option. Until I saw this thread, I was sure I caused the issue myself, as I had just recently added the following line (I could probably clean this command up a bit.):

/DietPi/dietpi/func/change_hostname $(echo “f3-”$(ip -4 addr show eth0 | grep -oP ‘inet \K.[\d.]+’ | grep -oP ‘\d{1,3}$’)"-cluster")

Basically, I set the hostname to f3-cluster in the dietpi.txt script, and the once I get to run my own bash I updated the hostname to include the last quartet of the IP.

Originally I tried setting the hostname in the dietpi.txt like above, found it doesn’t execute the code. Then I updated with hostname, but I found that the RAMDisk dietpi parts seemed to not like that.

I’ve had a thought that maybe this isn’t the best way to update the hostname, and that I might be making the device register as a new install somehow because I missed a config step.

Is this related to my upgrade path and I just need to update to the latest version? Or did I mess up something with how I change my hostname? I’ll likely reflash one of the SDs and try rerunning without the hostname change and see if it still happens.

Edit/Add: Hostname thing wasn’t the cause. Is it my upgrade path? I’m going to try the latest image and see if it happens without upgrading.

Edit/Add again: Now it’s working in general. It works with the newest image, and it works with my old 6.14 image with or without changing the hostname. I dunno, nothing appears to be different on my end. Resolved I hope! :slight_smile:

Thanks for feedback, so v6.21 finally solved everything as intended.