Another error message from the attempt to move an existing MySQL installation to a new server, this time caused by the import of all the old users from the old server. debian (and Ubuntu) adds their own user to the server to be able to perform upgrades and other maintenance through automagical scripts. The password that debian (or Ubuntu) uses to connect to this user is stored in a file on the local file system: /etc/mysql/debian.cnf.
This file contains the current password for the debian-sys-maint user, and if you’re moving all your users to a new server, be sure to also get this password from the file on the old server and copy it into the file on the new server. I strongly suggest copying just the password and not the whole file, as there may be new settings added to the file since you last upgraded the old server.
After moving a complete SQL dump from a MySQL 5.0 server to a MySQL 5.1 server I forgot about any issues stemming from the different versions of MySQL. Importing the old information_schema tables and any possible changes for the mysql table itself made it barf out the error message “ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by Event Scheduler were found damaged at server start” when trying to connect to the server.
The connection were still made, but obviously something were afoot. A few pages hinted in the direction of using mysql_upgrade to upgrade the now 5.0-compatible tables to the 5.1 format, but mysql_upgrade didn’t seem to want to run (maybe because of a new root password / debian-sys-maint password). The solution was to tell mysql_upgrade to ask for a password, which user it should connect as and which server it should connect to. You should run this command as root (preferrably through sudo) so that it can run mysql_fix_privilege_tables with the correct permissions:
sudo mysql_upgrade -u root -h localhost -p --verbose --force
The --force parameter will make the command run even if it thinks your server already has been upgraded to 5.1 (or the current version if you’re reading this at a later time). It may think this if you’ve already performed parts of the upgrade, but failed when trying to do the mysql_fix_privilege_tables-bit.
And away we went!