Yes, I'm the whole stack. The server runs in my home. I bought the server, installed the OS, the management interface, and manage all the sites on it. I'm the admin and sole teacher on my Moodle site.
It was this command that I tried linking to in my last reply
/usr/bin/php /path/to/moodle/admin/cli/install.phpbut I missed the mark by a bit. You confirmed that was the next thing to do in your last message so now I just have to start doing it. I'm going to try it while leaving my current config.php in place to see if that makes it easier. I feel like there may be some other file that indicates the installer shouldn't run, but that may be a Nextcloud system memory I'm having.
I know just enough about Git to know it's amazing, but it's too early for me to need to know more about it than the clone and pull commands. I ran a gitlab site for a while just to see if I could but didn't really need it so I shut it down.
As I got to the database part of a reinstall in our thread here I started to realize that I might know the root cause of this whole mess.
When Ubuntu 18.04 came out with a stable release, I thought, sure, why not upgrade now before I'm into production mode. All my sites and databases were backed up. I used the normal console command and upgrade prompts at the server's terminal. Well, the pattern was very different than all the other Ubuntu server installs I did. At one point it asked about overwriting my Postfix eMail system settings, and the option was to accept, reject, or view the changes. I asked to view. That may have launched the "vi" editor (which I never used before) and I had no prompt for leaving the view so I tried Ctrl+"C". Well, it dropped to a shell prompt and the upgrade was ruined. I had a non-working server. The attempts at a clean install with 18.04 were failing, so I had to do the bare bones 16.04 install then upgrade to 18.04 before adding all the software I need for my various projects.
At that point I thought, it's a great time to switch from MySQL to MariaDB, since it's a plugin-replacement, right? Well, no it isn't. It turns out that if you first launched a site like Moodle onto a MySQL database, then try to import that database to MariaDB, you're in trouble.
At some recent point in the past, MySQL decided to make the primary key for a char column able to be the full 255 max char column/field limit. It's crazy to have a char field as a primary key, but it's useful at times. When the developer of something like Moodle makes a table and they need a char field for maybe a max of 50 char's, but they don't specify 50, the database assumes the max size and makes it a 255 wide field. If it's a primary or a unique indexed field, that key is also accommodating that sized hash or whatever it manages the uniqueness with; that unique thing in the background is way bigger than the char field size and its size depends on the specified number of characters. MariaDB didn't make that keyspace bigger as MySQL did so the import fails when migrating from one to the other.
As a workaround, I wrote a SED script that would alter the char field sizes in the backup database dump from 255 to 191 if they were also key fields. I'm pretty sure that alteration may have added just enough bug in my system that the upgrade failed.
So this will be the first time I build a new Moodle database into MariaDB. I think it should go fine, but if it doesn't I have a second server still running MySQL that I can delegate the data to.
When I started this help me thread, I hoped the answer would have been, try clearing browser cache, or rub a buddha belly and chant your mantra.