That seems to have been it. The f17 rpm seems to have been compiled only for postgress. You would appear to be stuffed if using the rpm version now. I guess now MySQL is an Oracle product its not seen as a future supported direction by RedHat ?.
As I use bacula I banged away at this for quite a bit; and ended up getting it working from source which at least I could configure to use MySQL.
I downloaded the latest source (5.2.6) from
http://www.bacula.org/en/ and compiled it into /usr/local with (note: even though the configure help says the default is /usr/local, it doesn't seem to be so specify) And you may need to yum install mysql-devel if you don't already have it.
./configure --prefix=/usr/local --with-mysql
make
make install
I had to copy my *conf scripts from /etc/bacula over the supplied ones in /usr/local/etc; and used the "/usr/local/etc/bacula start" to start it.
The message changes to unable to connect to MySQL database which was an improvement. That seems to have been just table changes.
Used the contents of /usr/local/etc/update_mysql_tables to upgrade from version 12 (which is what the rpm version in f16 provided) to 14 which is what this version wanted. Which took just ages as I had a lot of data in File table being altered, but better than losing data. The update of the version value in the Version table failed as I had MySQL configured for safe mode; fixed manually by just dropping the version table and recreating it with the correct version based on the section for that in /usr/local/etc/make_mysql_tables (kust the bit that created the Version table and put the value in).
After that all was ok. Everything worked again ok.
[root@falcon etc]# uname -a
Linux falcon 3.3.7-1.fc17.i686 #1 SMP Mon May 21 22:50:24 UTC 2012 i686 i686 i386 GNU/Linux
[root@falcon etc]# ./bacula start
Starting the Bacula Storage daemon
Starting the Bacula File daemon
Starting the Bacula Director daemon
[root@falcon etc]# netstat -an | grep 910
tcp 0 0 0.0.0.0:9101 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9102 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9103 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.183:22 192.168.1.187:4910 ESTABLISHED
[root@falcon etc]# bconsole
Connecting to Director falcon:9101
1000 OK: bacula-dir Version: 5.2.6 (21 February 2012)
Enter a period to cancel a command.
*status dir
bacula-dir Version: 5.2.6 (21 February 2012) i686-pc-linux-gnu redhat Miracle)
Daemon started 04-Jun-12 11:40. Jobs: run=0, running=0 mode=0,0
Heap: heap=135,168 smbytes=52,701 max_bytes=53,898 bufs=292 max_bufs=302
Scheduled Jobs:
Level Type Pri Scheduled Name Volume
================================================== =================================
(lots of jobs displayed)
====
Running Jobs:
Console connected at 04-Jun-12 11:40
No Jobs running.
====
Terminated Jobs:
JobId Level Files Bytes Status Finished Name
================================================== ==================
(lots of jobs displayed)
====
*quit
Also... I did a file restore from a backup taken from the server that has bacula-dir running on it from when it was still on f16. All good; so no data lost.
My next steps are to delete all the rpms for bacula (as using rpms is what caused this upgrade to break f17 bacula for existing users that used mysql); try and install it from source somewhere else (as I can see having eveything in /usr/local (including logs in /usr/local/var/bacula/working instead of /var/log/bacula) is going to confuse me at some point) and put them into systemctl rather than having to use /usr/local/etc/bacula to stop/start things. But thats what I'll play with.
How to get a working bacula install on f17 using MySQL without losing any data after upgrading from f16 to f17 is just to go back to using source.
And maybe reviewing any other apps that use MySQL and getting the source for those in case the rpm versions of those stop working in a later update.
Linear Mode
