Don’t Upgrade vCenter Server Appliance From 5.0 to 5.1

Thinking of upgrading your vCenter Server Appliance from a 5.0 image to the 5.1 image using the official VMware upgrade process covered in the documentationDon’t do it. It fails somehow. Every time.

Screen Shot 2013-06-27 at 3.08.32 PM

 

Unexpected error during the upgrade process.

To attempt to upgrade again, restore the old vCenter Server Appliance and external database from backup/snapshot, deploy the new vCenter Server Appliance again and start the upgrade process from the beginning.

Yeah.. you read the right. Now both your old and new appliance images are b0rked, and you’ll need to restore from the vCenter 5.0 backup that you definitely made before attempting the upgrade. In private emails, VMware has acknowledged the issues and has advised to stick with 5.0 and hold off on upgrading the vCenter Server appliance until the next major release since the upgrade/migration tools are such horrible crap. Time to sit back and wait it out!

 

Update: The built-in update tool in 5.0 that allows you to apply point release upgrades is also fairly broken. (See the red “Failed to install..” message in the background?)

Screen Shot 2013-06-27 at 3.26.14 PM

Upgrading From Ruby 1.9.1 to Ruby 1.9.2

I’ve spent half the day so far inbeded in the furious stressful upgrade process of a handful of Ubuntu Linux 10.04 and Mac OS X Snow Leopard systems from Ruby 1.9.1 to Ruby 1.9.2. I haven’t even gotten to the Rails 3.0.0 stuff yet: just the baseline Ruby installation. I’ve gone through the upgrade process on both types of systems so far and the base issues have been the same. Here’s a common issue that many people are running into:

preston$ gem1.9

/opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:68:in `installed_spec_directories’: undefined method `path’ for Gem:Module (NoMethodError)
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems’
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index’
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs’
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize’
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new’
from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher’
from <internal:prelude>:10:in `synchronize’
<…and so on…>

Assuming you’re upgrading from a previous Ruby installation, note that the “site_ruby” directories are no longer used, and will eff up your 1.9.2 installation if you fail to delete them after the install. On OS X, run:

sudo rm -rf /opt/local/lib/ruby1.9/site_ruby/

On Ubuntu Linux 10.04, run:

rm -rf /usr/local/lib/ruby/site_ruby/

…to correct this issue. All note that you may see errors such as this:

root@li92-132:~# rake –version

/usr/local/lib/ruby/1.9.1/rubygems.rb:340:in `bin_path’: can’t find executable rake for rake-0.8.7 (Gem::Exception)

from /usr/local/bin/rake:19:in `<main>’

…despite have a rake gem installed. Apparently 1.9.2 comes with a version of rake internally, but is unable to find it for some reason relating to the rake.gemspec file. Remove the file to fix this issue. On Ubuntu Linux 10.04, run:
rm /usr/local/lib/ruby/gems/1.9.1/specifications/rake.gemspec
Notice the “1.9.1” path of the PATH. Yeah.. it’s weird. But for compatibility reasons your 1.9.2 installation will continue to use a path with 1.9.1. To quote the Ruby 1.9.2 FAQ page:
The standard library is installed in /usr/local/lib/ruby/1.9.1
This version number is “library compatibility version”. Ruby 1.9.2 is mostly compatible with the 1.9.1, so its library is installed in the directory.
I’m sure there’s a wonderful technical reason for this, but it’s still misleading and confusing as hell. I ended up manually deleting a bunch of stuff I shouldn’t have because I thought I was innocently “cleaning up” after the old version. Whatever. Additional suggestions:
  • Just to keep things clean, you may also want to remove your old Ruby 1.8.x builds. (I recommend doing so unless you have older apps that haven’t moved to 1.9.x yet.)
  • Phusion Passenger seems to work fine on Ubuntu 10.04 with the latest version of Apache 2 as of this writing, though don’t forget to recompile, reinstall, reconfigure and restart apache2 when you do so.
  • Check if you still need rack v1.0.1 installed (for older Rails app) before nuking everything. 🙁
I need a beer!

MacPort MySQL “Can’t find file: ‘./mysql/host.frm'” Error

I recently set up a new Mac OS X Snow Leopard laptop for software development purposes. After going through my usual MacPorts installation and installed MySQL using the following steps

  1. sudo install mysql5-server
  2. sudo cp /opt/local/var/macports/software/mysql5/5.1.44_0/opt/local/share/mysql5/mysql/my-medium.cnf /opt/local/etc/mysql5/my.cnf
  3. sudo -u mysql mysql_install_db5
  4. sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

A few days past, and one day I notice that launchctl was loading the script, but `nmap localhost` did not show the the process listening on port 3306 as expected. I looked at the log file:

sudo tail -f /opt/local/var/db/mysql5/preston.local.err

..and noticed it was terminating with the following errors:

100331 12:05:30 [ERROR] /opt/local/libexec/mysqld: Can’t find file: ‘./mysql/host.frm’ (errno: 13)
100331 12:05:30 [ERROR] Fatal error: Can’t open and lock privilege tables: Can’t find file: ‘./mysql/host.frm’ (errno: 13)

100331 12:05:30 [ERROR] /opt/local/libexec/mysqld: Can’t find file: ‘./mysql/host.frm’ (errno: 13)100331 12:05:30 [ERROR] Fatal error: Can’t open and lock privilege tables: Can’t find file: ‘./mysql/host.frm’ (errno: 13)

After a considerable amount of grief I evertually discovered that the contents of /opt/local/var/db/mysql5/ need to be owned by the appropriate mysql user (in my case “_mysql”), but some files were being owned by the “root” user. After correcting all file ownership and restarting the service…

  1. sudo chown -R _mysql /opt/local/var/db/mysql5/
  2. sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
  3. sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Everything now seems to work fine again. Hope this helps!

My iPhone 2.0 Upgrade Not Reactivating

It seems like there’s some sort of service outages with the iTunes store related to users upgrading to the iPhone 2.0 firmware. The firmware download and upgrade process seems to have upgrade fine, but mine is stuck on the please-connect-to-itunes screen. All I can do right now is view the IMEI and ICCID, and make emergency calls.

Update: After 4 continuous hours of having it plugged in, it finally reactivated and synced. PITA, but the new apps are hot!!!