Radmind, 10.4.8, and Intel

Quite a while back, I did a series of posts on using radmind to update a machine from 10.3.x to 10.4.x. A major element of the strategy, developed by Andrew Mortenson, was to copy vital tools and their needed libraries to a “cache” directory and coerce the OS to use those copies instead. This worked around problems to reared their heads when radmind replaced those tools and libraries while it was updating the filesystem.

While working on building a radmind loadset for 10.4.8, I discovered that if I used my current script to have radmind update an Intel Mac from 10.4.7 to 10.4.8, that the machine would hang when the script attempted to reboot the machine. You could manually reboot it, and the machine would come up fine. This behavior seemed very similar to what happened when trying to go from 10.3.x to 10.4.x before I implemented Andrew’s technique. It seemed that Andrew’s technique didn’t go quite far enough. There was much discussion of the issue on the radmind-users mailing list, and Ian Ward Comfort of Stanford came up with a solution. It takes Andrew’s ideas, and builds on them in two ways:

1. It dynamically determines if any tools or required libraries need to be cached, using Apple’s otool tool.
2. If /usr/lib/dyld is being replaced, it calls all the tools using a chroot-ed environment so that the cached version of dyld is used. This was the key change for the 10.4.7 to 10.4.8 update on Intel – without the chroot-ed environment, the OS was calling dyld in its original location after radmind had swapped it out, leading to a crash.

In my testing, this technique works perfectly. Here is Ian’s script, and here’s a link to the tool-caching bit of code. I did a lot of hacking to meld Ian’s code with mine, and I’ll probably post my version of the script soon.

Advertisement