This entry is a continuation of the previous one. Not only in the series, but also in terms of content.

In my estimation, the time had come for an official install of Ubuntu 22:04 LTS (Jammy Jellyfish) in combination with a production install of Virtualmin. Not that Vimexx has now released Jammy for a direct install on the VPS, but that doesn't matter. With a do-release-upgrade, that's taken care of quickly enough. Then I downloaded the latest Virtualmin install script and started it. Last time (see the blog of September 18th) I had done about the same, but then with a beta version of the install script. That led nowhere then, and I had the same experience again now.

And that was SH*T!

I had made a full backup via the standard Virtualmin backup procedure. In addition, I had made a backup of the entire /home folder. I had done the latter because I did not know exactly what is included in the standard backup. Besides, I had made it a few days earlier, and with the home backup, I now had all the e-mails with me. In short, I was ready.

However, after the re-installation of Jammy, followed by a run of the latest Virtualmin install script, the backup refused to restore! As the blog of September 18 shows, that was my experience at the time, but I blamed it on wrong decisions on my part. However, the truth turned out to be different, and more succinct... This backup just didn't want to be restored!!! That meant I had a problem. If I didn't know exactly what caused the error I'd be in the sh*t! Of course, I could try to restore the old situation, but I wasn't quite sure if that would work. After all, Virtualmin no longer supplies the install script that had determined the previous setup. I still had a version of that script myself, so I probably would have done it, but still... Ghost errors are the worst. So dived deeper into the sh*t. Some of the restore errors were due to the lack of support for mod_dav in the latest version of Virtualmin. And all websites were saved with a working /DAV. I never did anything with that, so that was quickly resolved. Deleted the definition of /DAV from all virtual servers, and restarted the restore. Error messages came about an already existing and non-writable web folder. How is that possible? Errors in the folder structure? Then I restored the backup of the home folder and restored the websites again. And yes, that solved a lot of trouble and showed the true error.

And now I come to the title of this blog entry, which at the same time points back to a blog from February 22, 2020! Michelle (usually called "My") and Maria are the daughters of Ulf Michael ("Monty") Widenius.

Or to put it differently and more clearly: without my realizing it, my VPS had been saddled with version 8.0.31 of MySQL, instead of a version of MariaDB. And even worse: MySQL databases cannot just be read into MariaDB.

In retrospect, I understand what happened. The blog of 2/22/2020 was caused by Drupal-7 not being able to handle the Oracle version of MySQL at the time. Drupal-8 and later Drupal-9 could, but all Drupals also work fine with MariaDB. So then the problem was solved. But now I am two providers and two VPSs further. During the installation of the Vimexx-VPS I didn't think about the database problem at all, just the default Ubuntu 20:04 with the then-available Virtualmin install script. That then led to an installation with MySQL 8.0.31. Meanwhile, Drupal-7 had been modified to run on this version of MySQL as well, so I didn't notice the My/Maria nonsense.

But meanwhile, the IT world has changed course a bit. MariaDB is now preferred for these types of applications. I understand there are good reasons for that. And to be honest, someone who is really into the matter will not be surprised by this hassle. But well... grandpa is also a bit retired, and datamess stuff is usually far from my concerns. An additional problem is that as a simple website builder you should not want to try to combine My and her sister. That just doesn't work. So no smooth transition is possible.

This nonsense took me about three days. It could have been faster, but as a grandfather, you also have to pay attention to grandchildren in between. In the end, Google saved me because if I have a problem, I'm sure I'm not the first.

The solution consisted of the following steps: first restored the backup of the VPS on my home server. It also turned out to run MySQL 8.0.31, and I could use that nicely. Then via a mysqldump enhanced with very sophisticated options, I exported the databases. Then I installed on the VPS Ubuntu 22:04 with the latest Virtualmin install script over it, so I got the latest version of all apps, including MariaDB. Then on the VPS, I did restore the virtual servers, the home folder, and again the virtual servers, until it choked reading the databases. Finally, read the database export dump from the home server onto the VPS. And yes... Wednesday morning October 26th. I started the operation (after making the backup in the days before) and on Friday-evening October 28th. I was finally ready. (Actually, it was now Saturday morning, but well...) 29 and 30 October used to fine-tune and finish everything. And now I'm finally where I want to be: the VPS runs under Jammy Jellyfish with Virtualmin 7.3-1 and MariaDB 10.6.7.

If that works for a while I will also try to get the home server that far. And then I can put Monty's daughters out of my mind...