During a thunderstorm, the power supply of my computer was damaged. After replacing the power supply, I was having problems with the HD my Ubuntu 22.04 Linux is on. Finally, I could only boot to an emergency command line prompt. And that didn't work. I had a screwed up alternate copy of Ubuntu 22.04 on another drive which I used for some purposed but not for CQRLOG. I moved to Windows for my digital work which is where I have contacts logged.
I was given a better computer than what I had and with the current state of component costs that was great. Due to frustrations with Ubuntu, I moved to Linux Mint (I know, it is based on Ubuntu but ...). The MariaDB files on the old computer can be read. I tried setting up CQRLOG on the new computer using the old files but all I get is the infamous TMySQL57 server connect error. The MariaDB server on the old computer was also used for running a small website (LAMP and Wordpress), so it was set up with the datafiles in /var/lib/mysql. I have port 3306 opened in ufw.
Any help in trying to fix this would be appreciated so I can recover my past contacts.
HI!
Sad to hear you have had problems with your hardware.
As first questions:
------------------
What was the Cqrlog version you used?
It is easiest to try with same version on recovered computer.
-----------
Did you use "save log data to local machine" or did you use MariaDB at localhost:3306 as log server ?
In case you used "save log data to local machine" your log databases are in ~/.config/cqrlog/database as in that case Cqrlog starts a new MariaDB thread using that folder as base.
How ever also in this case there is some information in database mysql (that is in mysql root directory /var/lib/mysql).
At least select * from mysql.innodb_table_stats; shows some information of cqrlog databases and sometimes this can be a reason that mess up recovered MariaDB of Cqrlog, even when ~/.config/cqrlog/database is restored from backup.
That is a thing I can not say how to fix it.
But I have had this kind of problem far in past and if I remember right only way was to clean up ~/.config/cqrlog folder, start from scratch and then import logs from adif backups.
Another hint is to remove all ib_logfileX files from ~/.config/cqrlog/database where X may be any number. and also mysql.err file.
Then new start of Cqrlog and data in mysql.err file is fresh and can be used to look what goes wrong.
------------
In case you have used MariaDB at localhost:3306 as log server recovering MariaDB from backup should restore your logs and website data.
Just remember that you need to create and give privileges to cqrlog database user to access MariaDB log databases.
------------
Ubuntu and variants are keen on installing Mysql as default. Are you sure your MariaDB is properly installed?
Check the file ~/.config/cqrlog/database/mysql.err . From very beginning you should see something like:
"2025-07-31 18:31:50 0 [Note] Starting MariaDB 10.11.11-MariaDB source re....."
If you can't see "MariaDB" but instead there is something like "Starting [mysql...." then you MariaDB installation is not OK.
For Cqrlog you need at least following packages:
sudo apt install libhamlib-utils libhamlib4 libmariadb-dev-compat libatk1.0-0 libcairo2 libgdk-pixbuf-2.0-0 libglib2.0-0 libgtk2.0-0 libpango-1.0-0 libx11-6 xplanet mariadb-client mariadb-server mariadb-common trustedqsl libssl-dev libqt5pas1
This list applies to Ubuntu 22.04 but should be nearly same with others , too.
--
Saku
OH1KH
I have been working on this. I use mariadb through 127.0.0.1:3306.
I deleted the ibdata1 and ib_logfile0 after purging mariadb from my system. I then re-installed mariadb. I can see the tables but not the columns in the tables. The error I am getting now is that the table is not in the engine when I try to look into any table within CQRLOG using mariadb in a terminal window or phpmyadmin. I have been digging into what that means. What I find is that the .frm and .ibd files have become disconnected.
I had no backups as this was a sudden failure.
Ok!
Lets start from beginning:
You had old computer with Cqrlog and you were using external database localhost at port 3306.
You had not checked "save log data to local machine", and so you have also database username and password you placed to Database connect window.
If I have understood right so far then your logs were somewhere along /var/lib/mysql path where your mysql (MariaDB) kept it's files.
You did not have any log data then in ~/.config/cqrog/database folder because of "save log data to local machine" was not checked.
You said you can see tables now, but no columns within, in you new PC. How can this be possible?
If a database table is created into mysql server it always have columns as it is the way how database table gets created. Columns and their types are told to sql engine and, based on that, it creates empty tables.
Something does not fit now, or otherwise I did not understood right.
If you really have had logs at external server localhost 3306 then you should try to restore folders what MariaDB was using. I assume they are somewhere at /var/lib path. But that may vary in different Linuxes. In my Fedora they are at /var/lib/mysql. After restoring them you have to create, or check that user still exist and is granted to have full control for databases whose name begins "cqr%" I.E. same way you had in your previous computer.
Rolling old folders over new MariaDB install may work, or may not. I have never tried that. It is maybe best to Google how old database server contents can be rescued from old disk. I am sure there are lots of hits for that.
I tried a test search with search words: "rescue old mariadb folders to new hard drive" and there seems to be lot of suggestions available.
Once your rescue is complete including database users, and you can seek database tables from terminal window's mysql (or mysqladmin) there should not be any problem to open them with cqrlog.
When that happens the first job to do is backup databases with mysqldump and copy ~/.config/cqrlog folder also to safe place with those dumps.
Together they make complete backup.
--
Saku
OH1KH