DNS config screen appears instead of dashboard after upgrade to Ubuntu 20.04 but upgrade seems to have been successful

[robw]

I've followed this process to upgrade Ubuntu 18.04 to 20.04 behind a Cloudron instance.

Everything appeared to run smoothly. MySQL 5.7 was uninstalled as part of the process and we kept the data, then installed MySQL 8.0 during post upgrade steps. This appeared to go well. We needed to perform the "Fixup collectd" step, and this appeared to work.

The CLI tests at the end of the upgrade guide all work - we have the right Ubuntu version, box is running, collectd is running. The server boots and all our apps appear to be working.

However after the upgrade accessing our dashboard shows the DNS setup screen instead of the dashboard. Attempting to go direct to deep URLs such as /#/apps just redirects back to the DNS setup screen. So we can't get into Cloudron to manage everything.

We have a server snapshot from before the upgrade, but of course data is already changing. So we'd prefer not to roll back and start over if possible.

Anyone seen this and/or got any tips?

[robi]

anything in the box logs to indicate why it isn't finding its existing config?

[robw]

No suspicious DNS related or dashboard related entries that I can see... We're using manual DNS but nothing has changed on that side.

In fact box.log contains some lines about ignoring a couple of SPF and DKIM errors that were there before the upgrade. (We haven't fixed up the DNS entry for one of the sub domains yet.) So it seems to me as though it is loading the previous configuration, which I guess accounts for our apps working too.

We have one unresponsive app. There are a few Open Project errors, I guess that's the unresponsive one.

[nebulon]

@robw maybe the Cloudron thinks its in some unitialized state now. If you want we can take a direct look at it, if you enable remote SSH support using the cloudron-support cli tool I guess https://docs.cloudron.io/support/#ssh-keys and send a mail to support@cloudron.io

[girish]

This is already solved in support@ . It somehow magically fixed itself...