This error is also discussed at length in bug report 59038 at
http://bugs.mysql.com/bug.php?id=59038
Within that report is a Dec 23 posting by Dave Kelly that identifies the problem and suggests a solution. There are four fields newly added to the mysql.user table that are constrained to be NOT NULL - which causes the installation wizard to fail when updating the root userid for first password and if you check the option to allow root to connect remotely.
These new NOT NULL fields also prevent windows client utilities such as Workbench and the older GUI Administrator tools from being able to add or change users. Any tool that attempts to add / change records in the user table directly will fail. Using the GRANT/REVOKE statements avoids this issue but it seems that a lot of tolls manipulate the user table directly.
I suspect that the Linux/Mac/? distributions have the same table design flaw. Perhaps their tools and clients avoid directly manipulating the mysql.user table.
Dave identifies the modifications to the user table that will resolve this problem. In the interests of expediency I implemented the changes:
ALTER TABLE `mysql`.`user` MODIFY COLUMN `ssl_cipher` BLOB NULL;
ALTER TABLE `mysql`.`user` MODIFY COLUMN `x509_issuer` BLOB NULL;
ALTER TABLE `mysql`.`user` MODIFY COLUMN `x509_subject` BLOB NULL;
ALTER TABLE `mysql`.`user` MODIFY COLUMN `authentication_string` TEXT NULL;
Others subsequently pointed out the risks in implementing a non standard change (a "hack") to the users table since it is an internal table to mysql. My own view is that since this change only relaxes a constraint for fields that previously did not exist, it's the only way to ensure backward compatibility. I predict that a future release of mysql 5.5 will implement this change.
As always - make changes at your own risk.
I must say, I was quite surprised that this design flaw was not caught during testing of the install wizard for windows.