[MDEV-5190] Packages not compatible with Ubuntu 13.04 due to mysql-common version difference Created: 2013-10-25 Updated: 2014-01-08 Resolved: 2014-01-08 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 5.5.33a |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | packaging | ||
| Environment: |
Ubuntu Raring (13.04) AMD64, MariaDB 5.5 series via official repo |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Today when updating one of our servers it decided to remove all MariaDB packages, both client and server were removed. This appears to be due to the fact that the mysql-common offered by the Ubuntu repository has a newer version (5.5.34-0ubuntu0.13.04.1) than the one offered by the MariaDB repository (5.5.33a+maria-1~raring). Could also be libmysqlclient18 which backwards depends on 5.5.34 as well. Doing apt-get dist-upgrade on a 13.04 server results in:
|
| Comments |
| Comment by Elena Stepanova [ 2013-10-25 ] |
|
Hi, This is a notoriously known issue that we can't do much about for the time being. Possible workarounds are described here: |
| Comment by Jill Miller [ 2013-12-08 ] |
|
Please help. I am on Ubuntu 13.10 (Saucy). AFter finally geetting MariaDB 5.5.33a working, I made the mistake of believing that moving to 5.5.34 might insulate me from this problem for a while. Unfortunately it has broken my MariaDB again exactly as indicated in the link supplied by Elena Stepanova. I have tried several solutions as suggested on help sites including completely removing MariaDB using Synaptic Package Manager, pinning the MariaDB repository per the instructions, then reinstalling. I still cannot complete the install of MariaDB. This is very frustrating. Is there something else I should do to clean up my MariaDB install? What if an automatic update breaks MariaDB for my client? I need a quick fix or I will not be able to use MariaDB for this one-desktop naive-client installation. Thanks for any help. |
| Comment by Elena Stepanova [ 2013-12-09 ] |
|
Hi, Generally moving to 5.5.34 should have helped for a while indeed, at least if you used dist-upgrade rather than just 'upgrade'. Please list the packages that are currently installed, something like To reduce the number of question/answer iterations, if you are getting something obscure like "Package X depends on package Y which is not going to be installed", without further explanation, please run and paste this error. Thanks. |
| Comment by Jill Miller [ 2013-12-09 ] |
|
Hi, Elena, and thank you again for coming to my rescue. I did not use upgrade or dist-upgrade. I could use some help finding the instructions for doing so. I include a copy of all the output from install (which I did because I'd uninstalled to clear the decks. It fails on restarting MariaDB after disabling Plugins 'InnoDB' and 'FEEDBACK' with the message "Package mariadb-server-5.5 is not configured yet.". The full listing plus the list of currently-installed packages of mariadb and mysql are in the attached file. Thank you, |
| Comment by Elena Stepanova [ 2013-12-09 ] |
|
Hi Jill, This "is not configured yet" error seems to be a general problem related to deb packages, which happens every now and then with anything. I could never find any good explanation on how to debug it or investigate the reasons, only solutions that helped somebody in some cases. Here are a few, in the order of brutality, ASC (please don't forget to backup your datadir and cnf files before trying any of these!) 1. http://askubuntu.com/questions/202321/package-dbus-is-not-configured-yet dpkg --configure -a if those don't work, which will most likely be the case, then aptitude install -f 2. http://askubuntu.com/questions/151510/how-can-i-resolve-dpkg-dependency-problems Remove packages that was unconfigured, in our case mariadb-server-5.5 sudo apt-get remove mariadb-server-5.5 Then run 3. Most brutal, and here you will certainly need the data backup: "Just fixed the problem by purging mysql* and mariadb*. Then removing all the traces of mysql by searching : find / -name mysql* Hope something of these works, please let us know how it goes. |
| Comment by Jill Miller [ 2013-12-10 ] |
|
Thanks again for your help. There's good news and bad news. First, the good news. Yesterday your advice worked like a charm on my personal laptop. Now, the bad news. Your suggestions did not fix the problems I'm having on my client's desktop. I attach a copy of the entire Terminal session including some things I tried before contacting JIRA. I've inserted dashes between commands to make it easier to read. Reading package lists... Error! Might this be important? Of course the very next command was 'sudo apt-get update' and it did not fix the problem. I can't tell you how much I appreciate your help. Thank you again. |
| Comment by Elena Stepanova [ 2013-12-10 ] |
|
Hi Jill, I doubt that the pkgcache issue is important or even related – as little as I know about apt, it looks to me to be just what it says, the list was somehow damaged, you ran apt-get update, it re-created the list, this particular problem was solved. Back to the MariaDB installation problem. Now, the persistent refusal to START server does ring the bell. The idea is that if there was a previously installed different version of MySQL on the machine, it might happen that the remaining config file in one of default locations contains options which are not recognizable by the version you are trying to install. It can happen in different upgrade/crossgrade paths: 5.1 => 5.5 (there were options deprecated in 5.1 and removed in 5.5); Percona => MariaDB (there might be Percona-only options that MariaDB does not recognize); 5.6 / 10.0 => 5.5 (there are lots of new options in MySQL 5.6 and MariaDB 10.0 which are not in 5.5). Please check the error log (and syslog) on your client's desktop. Unless it's a characters set related option (as it was in |
| Comment by Jill Miller [ 2013-12-12 ] |
|
Hi, Elena, Thanks for more suggestions. I doubt that the problem is related to cross versions. This (client's) desktop computer is one year old and never had any database earlier than mariadb_5.5.32. However, I did notice that an earlier error was referencing mysqld.sock. I do not find /var/run/mysqld/mysqld.sock (socket definition) on the client's computer. In fact there is nothing in /var/run/mysqld, although on my laptop that folder contains two files, mysqld.pid and mysqld.sock. I remember error messages relating to the .sock file. Might that be the source of my problem? If so, can I safely copy those files from my laptop to the client's computer? I have attached three files, A further copy of my terminal session with the same old error, a copy of syslog, and a copy of the my.cnf file. I don't have any errorlog file (what folder should it be in, it is not listed in the System Log applet of Ubuntu). I do have a file named system_log, but it is empty (0 bytes) and old (Oct 13). Thank you for your further help, |
| Comment by Elena Stepanova [ 2013-12-12 ] |
|
Hi Jill, The absence of socket/pid files means nothing, in fact it's totally normal since they are created automatically when the server is started. Since on your client's machine the server does not get started, the files are not created. The syslog clarifies a lot. Here is where the server startup fails: Dec 11 16:48:36 mikedesk mysqld: 131211 16:48:36 InnoDB: highest supported file format is Barracuda. What it means is that the InnoDB data structures are damaged. The most likely reason is that somebody tried to move data from some other machine to this one; or, it could happen if somebody tried to run clean installation and then restore the old data not by total replacing the datadir, but putting old files in the newly created datadir. |
| Comment by Jill Miller [ 2013-12-12 ] |
|
Hi, Elena, Aha! I think you've got it! That database, miketest, is the old one which was damaged. So, if I just remove that folder and its contents, do you think that will fix the problem? In which case, I may need some help removing it because, as I remember, I left it there because I had trouble deleting it. This also raises some other questions: If I were to develop the database on a different computer (my notebook, on which MariaDB now is working), then how could I move it onto the client's computer? What files would need to be moved, and how would I reset the password? Are there other considerations as well? Also, can you lead me toward on-line answers re any of these questions? I am very glad that this project is looking more hopeful. Thank you, thank you. --Jill Miller |
| Comment by Elena Stepanova [ 2013-12-12 ] |
|
Hi Jill, >> So, if I just remove that folder and its contents, do you think that will fix the problem? No, I think it might make the situation worse, that's exactly the kind of thing that would cause similar problems in the first place. For fixing it, your best shot is reading the article at the link that I posted above carefully and trying to apply it to your situation. It won't work 'as is", you'll have to adjust it. Unfortunately, there is no way to create a generic instruction for resolving it, because when it comes to this kind of damage/corruption, every case is unique and requires an individual approach. It's the same as with any application, basically – if you tamper with internal structures, you should expect problems which are not covered in the standard "user guide". If you can't fix it on your own, you might have to consider getting support involved. >> If I were to develop the database on a different computer (my notebook, on which MariaDB now is working), then how could I move it onto the client's computer? If you want to copy the entire database, the whole datadir, including system tables and everything, it should be as simple as shutting down your server properly, removing the whole datadir on the client machine and placing your entire datadir instead. You would reset the password in the usual way, as you always do, right before copying the datadir. If you only want to copy certain schema (or some of them), there are guidelines for copying/moving tables between machines in MySQL manual: |
| Comment by Jill Miller [ 2013-12-18 ] |
|
Hi, Elena, Hi Jill, >> So, if I just remove that folder and its contents, do you think that will fix the problem? Now you have scared me. I am NOT a mysql administrator and, although I used to be a machine language programmer, that was many, many years ago. I had trouble setting a password for myself in mariadb, so I could use the 'create database' command to have a database to connect to with LibreOffice Base. >> If I were to develop the database on a different computer (my notebook, on which MariaDB now is working), then how could I move it onto the client's computer? I am now working on doing the (re)programming of the database which is more like my area of expertise. As you can see, I have a LOT of holes in my knowledge. It would be very nice if I could find a support group or mysql/mariadb and LibreOffice Base gurus nearby. Do you know of any group in the Boston, Massachusetts area? Thank you again, from |
| Comment by Elena Stepanova [ 2014-01-08 ] |
|
Hi Jill, >> I am now working on doing the (re)programming of the database which is more like my area of expertise. As you can see, I have a LOT of holes in my knowledge. It would be very nice if I could find a support group or mysql/mariadb and LibreOffice Base gurus nearby. Do you know of any group in the Boston, Massachusetts area? Sorry did not see the question before, formatting went rogue. |
| Comment by Elena Stepanova [ 2014-01-08 ] |
|
All in all, the initial problem should be solved together with |