MySQL Error logs after upgrade

[scott]

Also are you using old_passwords=1 in /etc/my.cnf?

[jahwz]

Also are you using old_passwords=1 in /etc/my.cnf?

I did add 'old_passwords=1' before the initial restart after upgrading. Just now shutdown mysql, removed the old_passwords from my.cnf and the same error appears in the logs only when mysqld starts. HTH...

Code: Select all

060219 12:18:32  mysqld started
060219 12:18:32  InnoDB: Started; log sequence number 0 2170533
060219 12:18:32 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
060219 12:18:32 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
/usr/libexec/mysqld: ready for connections.
Version: '4.1.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

[scott]

Im guessing that time_zone_leap_second table is something it would set up on an initial install. I'm just speculating at this point since I cant duplicate it, but thats the kind of thing that would make an upgrade from 3->4.1 unworkable. If its true, then you'd have to remove mysql completely, install 4.1, and then re-import the older version 3 data. This is something to consult the mysql.com people about. I don't get into the internals of the way the DB server is set up.

[breun]

I also have the leap second table error in my logs, but MySQL seems to work just fine if I add 'old-passwords' to the first section of /etc/my.cnf (except for the problem I'm experiencing with a perl webapp).

[Stucco]

I've been wondering, is it

Code: Select all

old-passwords=1

or

Code: Select all

old_passwords=1

that goes in my.cnf?

[breun]

There is more than one way to make it work. I use just this in the first section of /etc/my.cnf:

old-passwords

(without and '=1' or 'set' or what have you.)

[scott]

Its: old_passwords=1