Bug #42397 Upgrading from setup.exe install to a .msi install is not recognized
Submitted: 27 Jan 2009 23:02 Modified: 9 Feb 2009 18:00
Reporter: Patrick Crews Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Config Wizard Severity:S3 (Non-critical)
Version:5.0+ OS:Windows
Assigned to: Assigned Account CPU Architecture:Any
Tags: install, msi, setup.exe, upgrade, vista, windows

[27 Jan 2009 23:02] Patrick Crews
Description:
Upgrading a MySQL installation from a setup.exe file by using a .msi file is not recognized as an upgrade.

NOTE:  This behavior was noted on Vista 64 bit, but it is not limited to this system

That is, the .msi installer normally recognizes an upgrade in version 5.1.29 -> 5.1.30, etc and behaves appropriately.  It will stop the current server and do some other things before proceeding with the new installation.

If you try this with the setup.exe -> .msi upgrade, a few issues occur:
1)  The current server is not stopped.  This results in a warning about the installation needing a currently used file (the current .pid file).  This *can* be ignored / installed over, but it is not elegant.

2)  The upgrade installation views itself as a clean install.  This runs into problems with existing passwords, especially when the default install and datadir values are used.  The .msi will not recognize that there is an existing password.
    2a)  As a result, if you try to set a root password, the Instance Configuration will fail (there is a pw needed, but not sent)
    2b)  If you do not change the pw setting, the Configuration will succeed, but you will not be able to log in to the server without the previous password.

How to repeat:
Install one version of the server via a setup.exe file, be sure to set the password and start MySQL as a service.

Install a newer version of the server via an msi file.

Observe the issues described above (.PID file needed but in use, password problems)

Suggested fix:
This is tricky.

Do we want to treat server versions as separate?  mysql-advanced-5.1.30 != mysql-enterprise-5.1.30.
This could be problematic for a customer upgrading from essential to enterprise (as an example)

Is 5.1.30-enterprise an upgrade for 5.1.29-advanced?

Depending on the answer, we need to upgrade the .msi to recognize these scenarios and handle them or to update the documentation to spell out what to do in such an upgrade scenario.
[5 Feb 2009 22:40] Iggy Galarza
I tested upgrading from the mysql-5.1.29 available on dev.mysql.com and a 5.1.31-essential installer package created with the changes for Bug#4217 on Windows XP and Vista (32-bit) and was unable to reproduce the problem.  This bug should be fixed in 5.1.32 so I'll mark it re-test to make sure bug reporter has same experience.
[9 Feb 2009 18:00] Patrick Crews
This behavior appears to be a symptom of:
Bug #4217	Multiple Uninstallation Entries in Add/Remove Programs

Tests with a .msi installer incorporating this bug fix could not repeat the problem.  Expect 5.1.32's .msi files to not have this issue.
[23 Feb 2009 20:41] Lars Heill
Tried on Vista x64:

1. installed mysql-5.1.30-winx64.zip/setup.exe
2. set password, started server
3. installed mysql-5.1.32-winx64.msi
4. configuration complained about pid in use
5. pressed "Ignore" (twice)
6. set new password
7. confirmed server running with new pid
8. connect with new password succeeded
9. uninstall with mysql-5.1.32-winx64.msi
10. uninstall complained, shut down process (the new pid)
11. uninstall complained, file (old pid) in use
12. pressed "Retry"
13. uninstall completed, service removed, MySQL/MySQL Server 5.1/bin dir remains (empty), my.ini remains, my <timestamp>.ini.bak remains.