Spent the better part of last week at work wrestling with an upgrade of Jaguar Server to Panther Server. There were a lot of things we wanted out of Panther — the honed Active Directory integration and overhauled mail server chiefly among them. The upgrade seemingly went fine, and we were back online in an hour. Then I hear from one of our Movable Type users that they’re getting errors trying to post stories. Hmm… the installation can’t seem to find the DBD::mysql module. It’s still there, I can see it. Reinstall the DBD package to be sure. Installs successfully, but problem persists. Compile Bundle::DBI and DBD::mysql from CPAN — the latter fails. Start doing research — I’m not the only one with this problem — some wonky interaction between multi-CPU threading, the version of perl installed with Panther Server, and the module in question.
Over the next few days, tried every possible trick I could think of or find reference to, but no joy. Editing bugs out of perl’s Config.pm, tweaking the makefile, changing environment variables. What tanned my hide was the fact that all of this worked perfectly before the upgrade. Some small bug buried somewhere in the bowels of perl or the OS wasting days of my time.
Finally ran out of options and decided to do a clean install rather than the upgrade, which meant recreating users and shares, updating databases, etc. Everything I had hoped to avoid. But after the clean install, three tweaks to the makefile and one to Config.pm convinced DBD::mysql to compile cleanly, and MT came back online.
Nothing is as simple as it seems. Nothing.
9 Replies to “Panther Server, DBD Hair-Pulling”
The panther installer (for desktop panther at least) is an abomination, it seems incapable of doing upgrade installs correctly. Apple should be embarassed to have released it. It sounds as though the Panther server installer is no better. Clean installs of Panther work nicely, it seems.
Not sure what you’re talking about, Jim. I’ve used the upgrade feature of the panther install program for at least 10 computers and all have worked fine. Care to explain what is wrong with the installer?
Yeah, I’m not so sure I’d be so harsh on it. This upgrade uncovered one lurking bug that happened to bite me pretty hard, but other than that, I was super impressed by the improvements in Panther Server, and everything else “just worked.” Same with Panther desktop upgrades – haven’t had a problem on any machine I’ve installed it on.
Scot, did you see this page?
It covers the problem with the DBI and DBD modules, and works without problem (I used it to get MT up and running on my Panther client G5).
Hi Jim – Yep, I saw that one and many others, all with slightly different takes on the problem. The only way that page relates to my problem was with the DBI and DBD package installers, which I installed (multiple times). Again, they would install just fine, but perl would still claim not to be able to find them. And building them from CPAN or download didn’t get me there either. :( Believe me, I banged on this for most of the week – I tried *everything*.
I think it was Brian Swetland who once told me that “There is no such thing as an OS upgrade.”
I’m convinced that starting from scratch with each major version of your OS is just the best long term policy. Not only do you rid yourself of all the package migration issues (which are never completely handled for people who thoroughly customize their machines) but you also clean out all of the leftover cruft from apps which you no longer use and which shouldn’t cause problems but often do.
Trevor, yep, I should have mentioned that in the end I was really happy to have a clean install. Apple cleaned up a bunch of things (like the locations of apache vhost configs) that were not touched in the upgrade.
There was an interesting project at PARC in which around 100 Windows2k machines were probed for configuration settings and a snapshot of their file systems. Then the stat weenies did a number on the data and it was startling to find just how radically different each installation was from the others. It wasn’t just that people had different sets of apps, but that with various service packs and installations the set of files and prefs which are the same on every machine were a miniscule portion of the whole.
There are a lot of ways to chop up that data, but I seem to remember them saying that the average overlap for machines running the “exact same version” of an OS was less than 1% for files by MD5 hash. It makes me shudder to think of what it would take to install consistently and correctly over such chaos.
About the Panther Desktop Installer:
The system I installed it on was originally configured (from a bare disk) with 10.1. Over time I’d installed all the 10.1 updates, 10.2, all the 10.2 updates, all with no problems. When I installed Panther update, it too seemed to have no problems, until I went to install the first of the downloadable updates, when it became clear that the Panther installer had left pieces of the old OSs lying around, which made the subsequent updates completely unstable. The pieces I can point at were things like some config screens used the 10.2 version instead of the 10.3 I can only assume that other, more important bits were similarly botched. With a system that wouldn’t boot, I was forced to do a wipe and install. Thankfully I’d backed my system up already.
On my wife’s Quicksilver, which hitherto had been running only os 9.2, the installer disk failed to load the install OS at all. It turned out there was a patch for the firmware in her superdrive, but of course we couldn’t install that with only classic running. We finally had to do her install off a firewire CDROM drive, then install the patch.
I realize these sorts of travails are perfectly normal in the Windows world, having experienced them frequently with Win95 OSR2, the version of that accursed OS which drove me to BeOS. But I do not expect them in the mac world. Not when a little testing should have made them abundantly obvious. To say nothing of the firewire drive corruption issue with 10.3.0.