Hi! On two boxes that I recently upgraded from F-10 to rawhide, I noticed that mysql 5.1 fails to restart with tables from 5.0. I have this error message in the mysql.log: 090331 19:37:38 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql /usr/libexec/mysqld: Table 'mysql.plugin' doesn't exist 090331 19:37:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 090331 19:37:39 InnoDB: Started; log sequence number 0 43655 090331 19:37:39 [ERROR] Fatal error: Can't open and lock privilege tables: Incorrect key file for table 'host'; try to repair it 090331 19:37:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Seems like the error message is pretty clear about what to do to fix it ...
Yes it is, but the problem is that mysqld doesn't start, and mysql_upgrade needs a running server.
I can't duplicate that here --- upgrading from a 5.0.77 installation to 5.1.32 works fine for me. So there's something important you forgot to mention about your 5.0 installation, or something different about the environment. (I'm testing this on F-10, don't have a machine I can update to rawhide right now.) Are there any AVC failures related to mysql in your logs?
ooh I see the problem. I have never run mysql_upgrade manually on these dbs previously. So they have probably been created by a version my mysql much much older than 5.0.77, with an older version de Fedora. As the mysql update from Fedora n to Fedora n+1, always worked fine without complaining, I totally missed the point that a new mysqld could have problems with old db/tables.
Hmm ... that's a bit nasty, but I'm not sure there's much I can do to fix it from a packaging standpoint. You might try reverting to whichever 5.0.x mysql you used last and running its mysql_upgrade, then see if you can update to 5.1 successfully.
Yes, I tried that, and it worked.
Good, I'm glad you got your data back. So that leaves us with the question of whether the mysql packaging could have done anything to prevent this. AFAICS the only thing it could really do is try to force running mysql_upgrade, but that seems like the kind of thing where the cure could be worse than the disease. Particularly if I were to try to apply it on an installation that hadn't gotten properly upgraded in the past ... who's to say how well mysql_upgrade would deal with that?
Yes, I agree that relying on the package scriplets to force mysql_upgrade while the user is upgrading his distribution is certainly not the best time for that. Maybe adding a warning in the F11 release notes about that case, would bring some benefits to other people that may encounter the same problem.
I've put a note about this into the F-11 release notes. Perhaps it will save somebody trouble.