Another Snow Leopard upgrade story

It may be that I’m a little paranoid, but I spent a full half day updating backups and two separate, and tested, clones of my main drive partition using SuperDuper.

This complete, I pushed the Mac OS X Snow Leopard Family Pack upgrade disc into the drive, and after a quick read, I’d signed away my life to Apple, pressed the install button, and found something else to do for the next hour.

I’d checked that all my key applications were compliant with Snow Leopard before I started, so the mainstream upgrade process was pretty painless: very promising for my chances of surviving my next upgrade.

I also remembered to install Xcode and the developer tools, vital for the next step.

The Pain of the Developer.

The problems started with the developer environment I’ve become accustom to using: PHP and Ruby. I started to wonder whether a clean install might have been a better idea.

I’m happy using the bundled Apache and PHP at the moment; these have been upgraded to versions 2.2.11 and 5.3 respectively, so there’s no major drama until they need to connect to MySQL.

Conversely, I prefer to build the majority of my tools from source in the /usr/local directory: MySQL, Ruby, RubyGems and Git.

Dan Benjamin has a great set of posts to help you do this, but he starts with a clean install, and if you’re upgrading it might not go so smoothly. Here are a few pointers gleaned from the Web and personal experience.

A new MySQL build.

I’ve been using version 5.0.51a for a while and decided to upgrade to 5.1.39 as part of the whole process. The first step was to create a dumpfile of the old database to upload into the new version:

mysqldump --opt -uroot -p --all-databases > currentdatabasedump.sql

In my experience, following Dan’s instructions gives great results, but I install each version into its own directory and symbolic link the one I want to use:

lrwxr-xr-x 1 root wheel 12 28 Oct 16:05 mysql -> mysql-5.1.39 drwxr-xr-x 12 root wheel 408 28 Oct 13:24 mysql-5.0.51a drwxr-xr-x 10 root wheel 340 28 Oct 16:07 mysql-5.1.39

Now to load the old databases into the new management system, so I logged in as root:

mysql -uroot

notice there’s no password yet, and from the mysql command line I loaded the contents of the dumpfile:

source path/to/dumpfile/currentdatabasedump.sql;

Finally, the databases need to be checked for incompatibilities and upgraded:

mysql_upgrade

and the database was acting like the old one, with the expected users and passwords assigned.

Why PHP still can’t use MySQL.

Snow Leopard doesn’t come with a php.ini file, so I copied /etc/php.ini.default to /etc/php.ini, but this file still needed a little modification to work with MySQL.

I changed all the occurrences of /var/mysql/mysql.sock to /tmp/mysql.sock, restarted Apache and my local WordPress installations were back in action, but MediaWiki wasn’t.

At this point the irony of having my troubleshooting notes in the form of a local wiki struck home, fortunately an upgrade to MediaWiki version 1.15.1 solved the problem.

Building Ruby, Rails and Gems.

I based my attempt on Dan’s instructions, and this time I was greeted by a series of make errors from readline.

Rob Seaman sums them up nicely and making the suggested adjustments to config.h allowed me to complete the installation.

I also tried to uninstall readline, but this only resulted in more errors, so pragmatically I upgraded to readline 6.0, and stuck to with the file modifications; must solve this problem one day…

Back to Dan for RubyGems, and installing the MySQL gem, and the first leg of the job was complete.

Rebuilding all the other gems.

Time to upgrade every gem, and gem update won’t do the job, they all need to be reinstalled. I picked up this handy line of Ruby code that can be run in irb from Victor Costan’s blog:

gem list.each_line {|line| system "sudo gem install #{line.split.first}"}

It executes the gem install command for every gem on your existing local list, and it was at this point that I noticed that the arrow keys were behaving strangely in irb.

It turns out that the readline extension isn’t installed along with the rest of Ruby:

cd /usr/local/src/ruby-1.8.7-p174/ext/readline ruby extconf.rb make sudo make install

should fix the problem.

The fly in the ointment.

Everything was going great, but whilst building the Nokogiri gem I ran into more errors. As Roger Neel worked out, I also tracked the problem to MacPorts, and the thing is that I can’t remember why it’s installed in the first place! So I took a risk, cloned first of course, and removed all traces of MacPorts:

sudo port -f uninstall installed

No good, MacPorts was too broken to uninstall itself, so next I took the direct approach:

sudo rm -rf /opt/local \ /Applications/MacPorts \ /Applications/DarwinPorts \ /Library/Tcl/macports1.0 \ /Library/Tcl/darwinports1.0 \ /Library/LaunchDaemons/org.macports.* \ /Library/StartupItems/DarwinPortsStartup \ /Library/Receipts/MacPorts.pkg \ /Library/Receipts/DarwinPorts.pkg \ ~/.macports

Gone, and with it the Nokogiri compilation errors, I can’t help wondering whether I’ll regret this step later… when I figure out why I installed it in the first place.

Building and installing Passenger.

Like all the gems, Passenger needs to be rebuilt using the new gcc compiler bundled with Xcode. My original Passenger configuration file disappeared from the /etc/apache2/other directory during the upgrade, so I made a new one:

-r--r--r-- 1 root wheel 73 18 May 20:44 bonjour.conf -rw-r--r-- 1 root wheel 287 28 Oct 20:06 passenger.conf -r--r--r-- 1 root wheel 194 18 May 20:44 php5.conf

This file contains the configuration instructions given at the end of the Passenger installation invoked by:

passenger-install-apache2-module

And Git.

Followed Dan’s recommendations and there were no problems.