# in-place upgrade from stock mysql 5.5 to Percona Server 5.6

**URL:** <https://forums.percona.com/t/in-place-upgrade-from-stock-mysql-5-5-to-percona-server-5-6/3100>\
**Category:** Percona Server for MySQL 5.6\
**Created:** [November 18, 2013, 1:35pm UTC](https://forums.percona.com/t/in-place-upgrade-from-stock-mysql-5-5-to-percona-server-5-6/3100 "2013-11-18T13:35:36Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rreddy](https://avatars.discourse-cdn.com/v4/letter/r/49beb7/32.png) [@rreddy](https://forums.percona.com/u/rreddy)\
**Post date:** [November 18, 2013, 1:35pm UTC](https://forums.percona.com/t/in-place-upgrade-from-stock-mysql-5-5-to-percona-server-5-6/3100/1 "2013-11-18T13:35:36Z")

</div>

Running into issue upgrading a copy of our production database. I have both the master/slave running on the same machine as this is a sand box used for testing.  
some of the users might have been created a long time ago using a very old mysql client. So I have already uninstalled the mysql 5.5 on this server and installed PS 5.6, how do I workaround this issue without having to update passwords for all the old users by re-installing stock mysql?

/usr/bin/mysql\_upgrade -u root -pxxxxxxxxxxxxx -S /mysql/sand1\_slavedb/sand1\_slavedb-sock  
Warning: Using a password on the command line interface can be insecure.  
Looking for ‘mysql’ as: /usr/bin/mysql  
Looking for ‘mysqlcheck’ as: /usr/bin/mysqlcheck  
Running ‘mysqlcheck’ with connection arguments: ‘–socket=/mysql/sand1/sand1-sock’ ‘–socket=/mysql/sand1\_slavedb/sand1\_slavedb-sock’  
Warning: Using a password on the command line interface can be insecure.  
Running ‘mysqlcheck’ with connection arguments: ‘–socket=/mysql/sand1/sand1-sock’ ‘–socket=/mysql/sand1\_slavedb/sand1\_slavedb-sock’  
Warning: Using a password on the command line interface can be insecure.  
mysql.columns\_priv OK  
mysql.db OK  
mysql.event OK  
mysql.func OK  
mysql.general\_log OK  
mysql.help\_category OK  
mysql.help\_keyword OK  
mysql.help\_relation OK  
mysql.help\_topic OK  
mysql.host OK  
mysql.innodb\_index\_stats OK  
mysql.innodb\_table\_stats OK  
mysql.ndb\_binlog\_index OK  
mysql.plugin OK  
mysql.proc OK  
mysql.procs\_priv OK  
mysql.proxies\_priv OK  
mysql.servers OK  
mysql.slave\_master\_info OK  
mysql.slave\_relay\_log\_info OK  
mysql.slave\_worker\_info OK  
mysql.slow\_log OK  
mysql.tables\_priv OK  
mysql.time\_zone OK  
mysql.time\_zone\_leap\_second OK  
mysql.time\_zone\_name OK  
mysql.time\_zone\_transition OK  
mysql.time\_zone\_transition\_type OK  
mysql.user OK  
Running ‘mysql\_fix\_privilege\_tables’…  
Warning: Using a password on the command line interface can be insecure.  
Warning 1642 Pre-4.1 password hash found. It is deprecated and will be removed in a future release. Please upgrade it to a new format.  
Running ‘mysqlcheck’ with connection arguments: ‘–socket=/mysql/sand1/sand1-sock’ ‘–socket=/mysql/sand1\_slavedb/sand1\_slavedb-sock’  
Warning: Using a password on the command line interface can be insecure.  
/usr/bin/mysqlcheck: Got error: 2049: Connection using old (pre-4.1.1) authentication protocol refused (client option ‘secure\_auth’ enabled) when trying to connect  
FATAL ERROR: Upgrade failed

---

<div class="post-metadata">

**Author:** ![rreddy](https://avatars.discourse-cdn.com/v4/letter/r/49beb7/32.png) [@rreddy](https://forums.percona.com/u/rreddy)\
**Post date:** [November 18, 2013, 3:45pm UTC](https://forums.percona.com/t/in-place-upgrade-from-stock-mysql-5-5-to-percona-server-5-6/3100/2 "2013-11-18T15:45:22Z")

</div>

secure\_auth is turned ON by default, some users created using the old password hashing algorithm were present. Rather than continuing on with the upgrade it just exits the upgrade process, will convert those old passwords to use new hashing, should be smooth next time.