| Bug #29378 | ERROR: 1136 Column count doesn't match value count at row 1 | ||
|---|---|---|---|
| Submitted: | 27 Jun 2007 6:37 | Modified: | 4 Sep 2008 7:56 |
| Reporter: | Aaron | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Installing | Severity: | S3 (Non-critical) |
| Version: | 5.0.41 | OS: | Linux |
| Assigned to: | CPU Architecture: | Any | |
[27 Jun 2007 6:37]
Aaron
[12 Jul 2007 20:31]
Aaron
Unfortunately, this is still a problem in 5.0.45: [root@host mysql5045]# rpm -Uvh MySQL-client-5.0.45-0.glibc23.i386.rpm MySQL-devel-5.0.45-0.glibc23.i386.rpm MySQL-server-5.0.45-0.glibc23.i386.rpm MySQL-shared-5.0.45-0.glibc23.i386.rpm warning: MySQL-client-5.0.45-0.glibc23.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5 Preparing... ########################################### [100%] 1:MySQL-shared ########################################### [ 25%] 2:MySQL-client ########################################### [ 50%] 3:MySQL-devel ########################################### [ 75%] Giving mysqld a couple of seconds to exit nicely 4:MySQL-server ########################################### [100%] ERROR: 1136 Column count doesn't match value count at row 1 070712 16:27:44 [ERROR] Aborting 070712 16:27:44 [Note] /usr/sbin/mysqld: Shutdown complete Installation of system tables failed! Examine the logs in /var/lib/mysql for more information. You can try to start the mysqld daemon with: /usr/sbin/mysqld --skip-grant & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables Try 'mysqld --help' if you have problems with paths. Using --log gives you a log in /var/lib/mysql that may be helpful. The latest information about MySQL is available on the web at http://www.mysql.com Please consult the MySQL manual section: 'Problems running mysql_install_db', and the manual section that describes problems on your OS. Another information source is the MySQL email archive. Please check all of the above before mailing us! And if you do mail us, you MUST use the /usr/bin/mysqlbug script! Starting MySQL SUCCESS! Thank you for installing the MySQL Community Server! For Production systems, we recommend MySQL Enterprise, which contains enterprise-ready software, intelligent advisory services, and full production support with scheduled service packs and more. Visit www.mysql.com/enterprise for more information.
[25 Aug 2007 17:40]
Aaron
I just read: The mysql_install_db script is used to create the MySQL grant tables with default privileges. This script is usually executed only once, when first installing MySQL on the system. The mysql_install_db script creates the mysql database which will hold all database and user privileges, the test database which you can use to test MySQL, and also privilege entries for the user that run mysql_install_db and a root user (without any passwords). Why are these binaries trying to run it again when I already have MySQL installed? I think that is the problem...
[25 Aug 2007 17:49]
Aaron
I now think this has something to do with: http://bugs.mysql.com/bug.php?id=27022
[27 Aug 2007 5:43]
Valeriy Kravchuk
Bug #27022 should be fixed in 5.0.40 and newer versions... What version/RPMs of MySQL you had installed before upgrading to 5.0.41 and 5.0.45?
[27 Aug 2007 5:45]
Aaron
Hi Valeriy, I was using 5.0.37.
[27 Aug 2007 10:11]
Magnus Blåudd
>ERROR: 1136 Column count doesn't match value count at row 1 This indicates there is am INSERT with different number of column specifications compared to values in the insert in the script to create the MySQL System tables. Those scripts are run everytime you upgrade incease any new system table should have been added or if the layout of them has changed. Any exiting data in the system tables should not be affected.
[27 Aug 2007 21:15]
Aaron
OK, well my point is that it didn't work right. I'm not doing anything with writing queries or doing SQL... I am just trying to upgrade MySQL rpms here. (Server Administration) It should have worked like it normally does. Do I really have to uninstall the MySQL rpms, erase the "mysql" database, and start over?
[23 Oct 2007 7:48]
Simon Tibidev
I had to change the /etc/my.cnf values and this issue was fixed. [mysqld] datadir=/usr/local/mysql/data socket=/tmp/mysql.sock #--datadir=/var/lib/mysql #--socket=/var/lib/mysql/mysql.sock # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 [mysql.server] user=mysql basedir=/usr/local/mysql #--basedir=/var/lib #[mysql.server] #user=mysql #basedir=/usr/local/mysql #datadir=/usr/local/mysql/data #pid-file=/usr/local/mysql/data [mysqld_safe] log-error=/var/log/mysqld.log ############################################ # please change server name to your servers name ############################################ pid-file=/usr/local/mysql/data/servername.com.pid #--log-error=/var/log/mysqld.log #--pid-file=/var/run/mysqld/mysqld.pid [client] socket=/tmp/mysql.sock [mysqld-4.0] new
[23 Oct 2007 17:28]
Aaron
But then the databases are in the wrong directory...
[29 Nov 2007 21:29]
Pedro Sousa
I run on this issue too and I solved it just moving /etc/my.cnf as bellow: /etc/my.cnf /etc/my.cnf.old After that error didn't happend again. Regards.
[29 Nov 2007 21:29]
Pedro Sousa
Sorry. Moved it making: mv /etc/my.cnf /etc/my.cnf.old
[29 Nov 2007 21:55]
Aaron
OK, except then you lose all of your settings. :) Even knowing that, your solution does not work for me. I have yet to find a real solution to this problem. The only workaround I have found is starting from fresh and reimporting the databases. The problem has to do with the "mysql" database. I really wish they would make this work. A lot of servers are sitting at 5.0.37 because of this bug.
[8 Dec 2007 5:44]
Lucio Codeghini
Aaron is spot on - I received exactly the same message when doing the following: Tried to upgrade from MySQL 4.1 to 5.0.45; Unistalled MySQL completely and attempted to install 5.0.45; I eventually found this bug report, installed 5.0.37, and everything worked like a dream. Running Fedora Core 6 on a low-spec development server.
[28 Apr 2008 20:34]
Sveta Smirnova
Could you please try with current version 5.0.51b and inform us if problem still exists. Thanks in advance.
[29 Apr 2008 6:10]
Aaron
I was unable to test 5.0.51b because there are no RPMs provided, but I did try 5.0.51a and it did the exact same thing. Was there something you specifically fixed in 5.0.51b that you wanted me to test, or did you just ask me to try it because it is the latest available release? Thanks.
[29 Apr 2008 13:39]
Sveta Smirnova
Thank you for the feedback. Yes, I asked to test, because 5.0.51b is last version and I can not repeat the problem in test environment.
[13 May 2008 20:00]
Sveta Smirnova
We still are not able to repeat the problem. Could you please provide your configuration file?
[13 May 2008 23:20]
Aaron
Hi Sveta, I am sorry for long time in between responses. The problem, for me, is that I have no more servers to test on. I mean that I had about ten servers that started out at MySQL version 4.1 and over time made their way up to MySQL 5.0.37. Well, all ten of these servers (also over time) have been upgraded past 5.0.37. They _all_ have received the original error in this bug report. The problem is that after I attempted an upgrade from 5.0.37 to 5.0.51a on my last servers, I now have no more servers to test it out on. I have tried installing 5.0.37 on a completely fresh/new server and upgrading that to 5.0.51a, but had no errors at all. (It worked correctly.) This leads me to believe that my problem is caused by upgrading MySQL versions all of these years. Right now, all of our servers got the original error I reported when I installed a version higher than 5.0.37, but they all seem to work correctly (ignoring that error). So, I hope that my existing MySQL installations are not messed up because of the error, but I have no way to test or tell you how to reproduce this bug. Sorry :(
[28 May 2008 19:28]
Steven Brady
I am having this problem on clean install of 5.1.24-rc on a sparc Solaris 10 host using pkgadd. ## Executing postinstall script. ERROR: 1136 Column count doesn't match value count at row 1 080528 14:21:19 [ERROR] Aborting 080528 14:21:19 [Note] /opt/mysql/mysql/bin/mysqld: Shutdown complete Installation of system tables failed! Examine the logs in Regards, Steve Brady
[4 Aug 2008 7:56]
Sveta Smirnova
Steven, thank you for the feedback. Please try with current version 5.1.26 and if problem still exists provide step-by-step description how you install MySQL server.
[4 Sep 2008 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[1 May 2009 1:05]
Brett Nemeroff
Hi All,
I know this is a pretty old bug by now, but I wanted to mention that I have a solution for this. I was upgrading from 5.0.x to 5.1.34 and got this exact same error. In my angst, I arrived here, hopeful to find a solution.
Turns out, the fault is mine. Mine, for not reading the entire error message. So I had an existing DB running. And duh, it had passwords and the like on it.. So of course, the rpms couldn't update the tables. So per the error message, I restarted the db like:
shell> /usr/sbin/mysqld --skip-grant &
Then noticed the console showed the message:
090430 20:58:42 [ERROR] Column count of mysql.db is wrong. Expected 22, found 20. Created with MySQL 50045, now running 50134. Please use mysql_upgrade to fix this error.
so I executed:
mysql_upgrade
Worked great.. now my db is happy. (of course, restarted db to use grant tables after that..)
[15 Aug 2009 9:18]
MIhai Cazac
Thank you, Brett, that worked for me, too!
