The worst problem for me following the upgrade was that I could not connect to the mail server. I tried with Thunderbird, with my android client (FairEmail) and with the web interface, all failed.

I know this is IMAP and I know it is handled by dovecot, so I went checking the service’s journal:

I went on checking the state of the service: systemctl status dovecot which told me how to generate a new DH key and set it up in the dovecot configuration and that is exactly what I did. Following that and a restart of both dovecot and sogo services, everything was working again.

I won’t go any further into the details, we will later see that I wasn’t supposed to do that.

I saw that in the meantime I had received several e-mails so that’s proof that my server was indeed still able to receive messages even though I could not retrieve them.

Nothing special there, same error than on the test instance, same solution, still not the best but I was still unwilling to look any further: reinstallation.

This was the big one. When connecting to the usual URL I get a Grafana page.

No way I could get lazy and do the same thing as lufi and lutim, I did not know how the application would react if I reinstall it, we’re talking about a federated social network with multiple connexions to other instances.

I had already had that problem in the past and had solved it quite easily with an update. So that’s what I tried…​

That was a big fat fail: I had launched the update at 8AM and when I checked at 6PM I saw that the update had failed and a restoration was running. The CPU load was off the charts and the system was swapping as hell, I decided to kill the process (Ctrl+C).

My instance had never been very fast but I had also never found it disturbingly slow. Nonetheless I upgraded the virtual machine from two to four CPUs.

New try, new fail, this time even quicker, which is quite logical since I had left the application in an unknown state when I killed the restoration process.

Since the restoration had not finished, the backup file was still in /home/yunohost.backup/tmp/ so I decided to use it:

It took several hours but it worked. Sadly, the app was still not working.

A yunohost service status tells me that mastodon-sidekiq and mastodon-web are stopped.

A systemctl status mastodon-sidekiq tells me amongst other things that gem nokogiri is missing.

Ok, so:

Since the missing gem and several others had been installed, I started the services that were failing:

Even though sidekiq did indeed restart, web was still reluctant.

systemctl status mastodon-web tells me that the port 3000 it wants to use is already taken.

netstat -tupanl | grep 3000 tells me the culprit is grafana. I try killing the process, no success. After a reboot everything works like a charm.

Now I’m thinking 'Nice, I am close to the goal, now that the application is working, I update it and everything will be fine'. I couldn’t be more wrong! I have a look at the error messages, something about a missing index, I am again facing a stuck restoration.

From what I read on the offical Mastodon repository this has nothing to do with Yunohost (the index thing). Whatever, I decide to restore the new pre-migration backup and take care of that later.

So now I do have a working mastodon but no up-to-date. To be continued…​

As stipulated in the documentation, I should have run the diagnosis before anything else, it would have spared me some debugging and manual modifications. I’ll think about it next time :)

After the reboot for mastodon, the diagnosis lists lufi as failing, the logs say that the database was still starting. A simple systemctl start lufi fixed it, I will have to nofity the package maintainer about that.

I had other warnings about configuration files that had been hand modified and had to be regenerated:

For each one of them I checked the diff, backed up the file and regenerated it, all that using the commands given by the diagnosis tool.

The problem with nslcd and nsswitch.conf is a known bug listed in the migration process page.

For dovecot.conf it had to do with the modification I described earlier and another one I talked about in another post.

For sshd_config it was about the listening port that I had changed and some other changes made by the update.

I restarded nslcd and dovecot to take the changes into account but I changed the ssh listen port to my custom value before restarting it.

After some tests, the connection problem I talked about a while back reappeared, so I applied the same solution.

I updated the applications that required Yunohost 4 and made sure to not list mastodon.

I still have to try to update mastodon, I’ll have a look at the suggested fixes from the issue open in the upstream repository. Unfortunately it has been opened since july and is still not solved.