You are not logged in.
Hi
That time I made it works...
I downgrade all the mysql packages, reconfigured it, and upgrading the packages
Everything is ok.
[but still when upgrading there is no my.conf.pacnew file....]
Serge
Offline
Didn´t work for me.
Offline
@csergec
Go back to mysql 5.1 so you can start the daemon, then repair your tables with mysqlcheck -Ap --auto-repair.
Then upgrade to mysql 5.5, fix any options needed and run mysql_upgrade -u root -p.
If that still doesn't work, post your my.conf and the log when you try to start.
Offline
Hi fphillips
Everything is ok now
Thank you
Serge
Offline
The first upgrade attempt with 5.5.8 failed and I couldn't even get the daemon to start until I removed my.cnf
Now 3 days later I see there is a new package 5.5.9 so I tried again only I can't get the daemon to start at all to even run mysql_update. I dumped my DB and ran mysqlcheck without errors. Finally I resolved to removing mysql completely (pacman -Rd mysql) but still no change.
How are some of you getting my.cnf.pacnew files and some not?
Offline
You can try starting without grant tables.
As root:
mysqld_safe --skip-grant-tables &
and then:
mysql_upgrade
As far as the "my.cnf", I did not get a ".pacnew". Mine was overwritten automatically by the upgrade.
*EDIT* fixed a typo.
Last edited by sim4lin (2011-02-10 10:20:58)
ASRock N68C-GS FX motherboard
AMD X2 240 @ 2.8G
Nvidia 9500GT @ 1G
Kingston 800Mhz DDR2 @ 4G
Offline
How are some of you getting my.cnf.pacnew files and some not?
I think the key is whether the my.cnf has been modified since it was installed. From https://wiki.archlinux.org/index.php/Pa … ckup_files
If the version of the file currently in the filesystem has been modified from the version originally installed by the package, pacman cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, pacman saves the new version with a .pacnew extension and leaves the modified version untouched.
Offline
OK I was thinking .pacnew is written only when config has been modified. Thanks for that link.
I was also unsuccessful wth --skip-grant & as suggested. Here is the latest error:
( 1/11) installing mysql [###################################] 100%
Installing MySQL system tables...
110209 20:40:06 [ERROR] /usr/bin/mysqld: unknown option '--skip-locking'
110209 20:40:06 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/var/lib/mysql for more information.
You can try to start the mysqld daemon with:
shell> /usr/bin/mysqld --skip-grant &
and here is the log:
110209 20:43:52 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110209 20:43:53 InnoDB: The InnoDB memory heap is disabled
110209 20:43:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110209 20:43:53 InnoDB: Compressed tables use zlib 1.2.5
110209 20:43:53 InnoDB: Initializing buffer pool, size = 128.0M
110209 20:43:53 InnoDB: Completed initialization of buffer pool
110209 20:43:53 InnoDB: highest supported file format is Barracuda.
110209 20:43:53 InnoDB: Waiting for the background threads to start
110209 20:43:54 InnoDB: 1.1.5 started; log sequence number 1589379
110209 20:43:54 [ERROR] /usr/bin/mysqld: unknown option '--skip-locking'
110209 20:43:54 [ERROR] Aborting
110209 20:43:54 InnoDB: Starting shutdown...
110209 20:43:54 InnoDB: Shutdown completed; log sequence number 1589379
Where do I go from here?
Offline
Does the [mysqld] section of your my.cnf have "skip-locking" or "skip-external-locking"? It should be the latter for v5.5.
ASRock N68C-GS FX motherboard
AMD X2 240 @ 2.8G
Nvidia 9500GT @ 1G
Kingston 800Mhz DDR2 @ 4G
Offline
I was having same issue with mysqld not starting, I wound up removing the /etc/my.cnf* files (I had a my.cnf, my.cnf~, my.cnf.backup, my.cnf.pacsave and my.cnf.pacnew in there!) as all were apparently conflicting. Removed those and mysql started properly. (It's only using /etc/mysql/my.cnf now I gather).
Offline
Now it gets weird: my.cnf reads "skip-external-locking". No matter how I try to start mysql after the upgrade I get an error
110210 23:27:34 [ERROR] /usr/bin/mysqld: unknown option '--skip-locking'
I deleted my.cnf and restarted and still get it.
Offline
There is a nasty upstream bug with this MySQL upgrade - http://bugs.mysql.com/bug.php?id=60061
It appears libmysqlclient is broken right now as I noticed I receive this message when starting a process requiring MySQL
/usr/lib/libmysqlclient.so.16: no version information available
libmysqlclient.so.16 is indeed in /usr/lib too. This has caused issues for me and it may be related to what others are facing.
Last edited by cirkit (2011-02-11 16:51:32)
Offline
I really like 5.5 and it being released fairly quick. I did miss the archive engine however; and needed to downgrade so I could access my data again. This might have nice to put in the upgrade warning Even better would be to add the engine again
Also, I am not very happy with /var/lib/mysql/test/.empty and /var/lib/mysql/mysql/.empty especially since they aren't owned by mysql:mysql. Is there any reason for this?
Last edited by Spider.007 (2011-02-13 17:45:26)
Offline
I really like 5.5 and it being released fairly quick. I did miss the archive engine however; and needed to downgrade so I could access my data again. This might have nice to put in the upgrade warning Even better would be to add the engine again
It was on the frontpage announcement.
Also, I am not very happy with /var/lib/mysql/test/.empty and /var/lib/mysql/mysql/.empty especially since they aren't owned by mysql:mysql. Is there any reason for this?
File a bug and see what the packager says.
Offline
Could someone please tell me why this is so complicated? I don't have time for this, I spend enough time keeping Arch running smoothly and do have a life outside of Arch and MySQL!
I completely removed mysql 5.1 and installed 5.5 clean
(1/1) installing mysql [############################################] 100%
Installing MySQL system tables...
110219 12:48:07 [ERROR] /usr/bin/mysqld: unknown option '--skip-locking'
110219 12:48:07 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/var/lib/mysql for more information.
You can try to start the mysqld daemon with:
shell> /usr/bin/mysqld --skip-grant &
/usr/bin/mysqld -u root --skip-grant &
[1] 4959
[dust@arch64 ~]$ 110219 12:55:03 InnoDB: The InnoDB memory heap is disabled
110219 12:55:03 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110219 12:55:03 InnoDB: Compressed tables use zlib 1.2.5
110219 12:55:03 InnoDB: Initializing buffer pool, size = 128.0M
110219 12:55:03 InnoDB: Completed initialization of buffer pool
110219 12:55:03 InnoDB: highest supported file format is Barracuda.
110219 12:55:03 InnoDB: Waiting for the background threads to start
110219 12:55:04 InnoDB: 1.1.5 started; log sequence number 1589379
110219 12:55:04 [ERROR] /usr/bin/mysqld: unknown option '--skip-locking'
110219 12:55:04 [ERROR] Aborting
110219 12:55:04 InnoDB: Starting shutdown...
110219 12:55:04 InnoDB: Shutdown completed; log sequence number 1589379
110219 12:55:04 [Note] /usr/bin/mysqld: Shutdown complete
Why and where in bloody hell is --skip-locking in there when it is a new install and configuration???
How do I run mysql to upgrade the tables when everything fails?
Is there anyone from Arch offering support?
Offline
you probably didn't remove /etc/my.cnf and it wasn't removed automatically either. So just update your config as described
Last edited by Spider.007 (2011-02-19 13:57:42)
Offline
pacman -Rd mysql AND I checked that /etc/mysql was not there after that.
And if you see that 2 posts after your reference I stated that even after deleting my.cnf - in which "skip-external-locking" was enabled - I still got the error!
Last edited by subatomic (2011-02-19 16:28:38)
Offline
I think you know that it is finding this option in some other my.cnf laying around on your system.
The package installs to /etc/mysql/my.cnf, not /etc/my.cnf, but it does check both places. It will also look in ~/.my.cnf.
In addition, check for /root/.my.cnf, /root/my.cnf, /var/lib/mysql/my.cnf just for completeness.
You are running the binary directly. Don't do this. This skips all the "environment" that would otherwise be setup.
Either use the init file: /usr/rc.d/mysqld start|stop
or the wrapper: /usr/bin/mysqld_safe
Mysql runs as mysql user, so the "-u root" option will be useless when using the above methods.
Offline
Hey! Thanks so much to Spider007 and fphillips!
There was actually another my.cnf in /etc - mysql_upgrade now successful!
Offline
hm, deleting my my.cnf, pacman -Rd mysql & reinstall solved my issues..
Thanks pal, worked for me too.
Offline
Regenwald wrote:hm, deleting my my.cnf, pacman -Rd mysql & reinstall solved my issues..
Thanks pal, worked for me too.
I faced a similar issue, tried to delete my.cnf and then pacman -S mysql without removing mysql first, but it didn't work. Then I tried Regenwald's solution (which adds the -Rdd step to what I tried before) and it worked also for me.
Last edited by snack (2011-04-09 14:35:42)
Offline