[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: Text File MariDBProb.txt     Text File MariDBProb2.txt     Text File MariaDBSyslogProb3     Text File MariaDBTerminalSessionProb3     Text File MariaDB_my_cnf_Prob3    
Issue Links:
PartOf
is part of MDEV-5252 Deb installation issues due to versio... Closed

 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:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
libmariadbclient18 mariadb-client mariadb-client-5.5 mariadb-client-core-5.5 mariadb-server mariadb-server-5.5 mariadb-server-core-5.5
The following NEW packages will be installed:
mysql-client mysql-client-5.5 mysql-client-core-5.5
The following packages will be upgraded:
libmysqlclient18 mysql-common
2 upgraded, 3 newly installed, 7 to remove and 0 not upgraded.
Need to get 11.0 MB of archives.
After this operation, 69.9 MB disk space will be freed.
Do you want to continue [Y/n]?



 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:
https://mariadb.com/kb/en/installing-mariadb-deb-files/#version-mismatch-between-mariadb-and-ubuntudebian-repositories

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'.
If you provide more information on what is broken now, we might be able to advise on fixing it.

Please list the packages that are currently installed, something like
dpkg -l | grep -iE '(maria|mysql)'
or anything alike that shows all installed maria and mysql packages, and also paste the exact error message that you are getting.

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
apt-get install Y
and so on until you get more information, like "Package Z-foo is needed, but Z-bar is going to be installed instead"

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,
--Jill <[1]Jill@millermicro.com>

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
apt-get install -f

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
sudo apt-get update && sudo apt-get dist-upgrade

3. Most brutal, and here you will certainly need the data backup:
http://askubuntu.com/questions/286476/cant-install-mariadb-5-5-or-10-in-ubuntu-12-04-mysqld-failed-to-start

"Just fixed the problem by purging mysql* and mariadb*. Then removing all the traces of mysql by searching :

find / -name mysql*
There were some leftovers in lib. After removing them, rebooted the server and installed mariadb again! It worked."

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.
Note that 'sudo apt-get remove mariadb-server-5.5' returned the following:

Reading package lists... Error!
E: Problem renaming the file /var/cache/apt/pkgcache.bin.pIoPfB to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory)
W: You may want to run apt-get update to correct these problems

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.
--Jill Miller

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.
Please take a look at MDEV-4111, specifically at this comment: http://tinyurl.com/q3fhl3v

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 MDEV-4111), the corresponding error message should be written to the error log. If there is nothing in the log, please check cnf files for the presence of charset-related options, comment all of them and try again (later you can go through them one by one and restore whatever is relevant).

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,
--Jill Miller

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.
Dec 11 16:48:36 mikedesk mysqld: InnoDB: The log sequence number in ibdata files does not match
Dec 11 16:48:36 mikedesk mysqld: InnoDB: the log sequence number in the ib_logfiles!
Dec 11 16:48:36 mikedesk mysqld: 131211 16:48:36 InnoDB: Database was not shut down normally!
Dec 11 16:48:36 mikedesk mysqld: InnoDB: Starting crash recovery.
Dec 11 16:48:36 mikedesk mysqld: InnoDB: Reading tablespace information from the .ibd files...
Dec 11 16:48:36 mikedesk mysqld: InnoDB: Error: trying to add tablespace 30 of name './miketest/JobCodes.ibd'
Dec 11 16:48:36 mikedesk mysqld: InnoDB: to the tablespace memory cache, but tablespace
Dec 11 16:48:36 mikedesk mysqld: InnoDB: 30 of name './eeodb/tblGeogNames.ibd' already exists in the tablespace
Dec 11 16:48:36 mikedesk mysqld: InnoDB: memory cache!
Dec 11 16:48:36 mikedesk mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended

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.
but I suppose nobody will ever admit to it, so lets say it got damaged due to some bad shutdown, power failure, disk failure or such.
The point is, you need to decide whether the data is valuable, and then try to fix it, in which case this article might help: http://www.mysqlperformanceblog.com/2011/05/13/connecting-orphaned-ibd-files/ .
Or, if you don't care about the old data, you can just remove the old datadir – all of it! – and start from scratch, that is, uninstall the server, purge it, remove /var/lib/mysql, and then install again.

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?
>> 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?

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:
http://dev.mysql.com/doc/refman/5.5/en/innodb-migration.html
http://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
These links point at the same page in 5.5 and 5.6 manuals, correspondingly. Even though you are on 5.5, you should read the 5.6 page as well, it contains more information which is partially applicable to 5.5 too.
For non-InnoDB tables, you can also search the manual.
As long as you don't copy system tables, you shouldn't worry about the password since it won't be copied anyway.

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?
> 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.

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?
>> 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?
> 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.
Because the MariaDB installation went bad before I got much work done in it, I removed everything and started over again. It is fortunate that I had all the initial data in spreadsheets and don't have to type it all in.

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
--Jill Miller <[1]Jill@millermicro.com>

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.
I don't know anything about groups in the USA, but if you are still interested, you might try to send the question to maria-discuss@lists.launchpad.net, maybe there are people who have information on the subject.

Comment by Elena Stepanova [ 2014-01-08 ]

All in all, the initial problem should be solved together with MDEV-5252.

Generated at Thu Feb 08 07:02:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.