Joshie.com

I have been using InstaDMG for a long time to make my Max OS X 10.5 Leopard and 10.6 Snow Leopard images. It always worked without flaw until recently. A technician mentioned to me that /Applications/Mail.app would not launch on my 10.5.8 image. I later also had some issues with the Finder that I just couldn't figure out. On an email list someone said they saw the same thing on 10.6 with the following error;

You have Mail version 4.0 (1075/1077). It can't be used on Mac OS X Version 10.6.2 (Build 10C540)

So what follows is how I addressed this issue. The issue has to do with relocation which is a relatively new feature in OS X's installer system. Basically the 10.5.8 or 10.6.2 update runs and instead of it updating Mail.app (and many other things) on the InstaDMG drive, it updates it on the drive you are booted from. I have an enhancement on file with Apple to add a switch to installer so that it will ignore relocation if you use the switch. Until then you will have to do the following to every Apple package you download to put in your OS updates folder. If you are reading this and don't know what InstaDMG is then most likely you can fix your problem by running either the 10.5.8 or 10.6.2 combo updates available on Apple's website in the Downloads area.

First you need to be able to edit Flat Packages. These are the new packages where you can no longer Right Click -> Show Package Contents anymore. If you are working with an older package then you can skip this step and just Right Click -> Show Package Contents.

• Install XCode on your workstation
• Launch /Developer/Applications/Utilities/PackageMaker
• Under the Edit menu pick to Open Flat Package Editor
• Once in Flat Package Editor you can File -> Open the Package to be edited.

 At this point you should see something like this; 

• Now you will drag the file PackageInfo to your desktop and open it in TextEdit and make the following changes;
  • Change relocatable="true" in the 2nd line to relocatable="false"
  • Delete everything from <deferred-install until </deferred-install> since that whole section is not needed.
  • Delete everything from <relocate search-id until the very last </relocate> so that nothing is marked for relocation.
  • Delete everything from <locator> until </locator> to strip the code that searches for relocatable stuff.
• Now highlight PackageInfo in Flat Package Editor and click the delete icon.
• Drag your modified PackageInfo in to the same place the previous one was.
• Save the modified package with File -> Save
• On the dialog that will appear you need to pick "No Identity" which will strip the package of it's certificate, but this does not matter. If you have your own certificate you could use that, but it's really not needed for this.

• Next I close Flat Package Editor, re-launch it, re-open the edited package, and drag the PackageInfo file to my desktop again and check it in TextEdit to make sure my edits stayed. I do this because I have seen Flat Package Editor not include my changed file. Until the very latest Xcode I also had issues with Flat Package Editor quitting mid-save as well.

You are now done. The edited package will not know about relocation. If you include it in your InstaDMG workflow you should not have any problems that relate to file relocation. I now do this to every Apple PKG I work with for InstaDMG.

[For those that don't know what InstaDMG is you should really check it out if you manage Macintosh systems. It's at www.afp548.com and is really really helpful.]

So I included the latest iTunes and noticed my DMG was still mounted when all was done. "lsof" is my friend and showed me there were two things in use that should not have been.

 

• /Volumes/OS-Build-08-03-15/Applications/iTunes.app/Contents/Resources/ iTunesHelper.app/Contents/MacOS/iTunesHelper
• /Volumes/OS-Build-08-03-15/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/ MobileDevice

I knew the framework was loaded from the binary since when I killed the iTunesHelper process the framework let go. Then I found this...

 

 

• /iTunes.mpkg/Contents/Resources/iTunesX.pkg/Contents/Resources/ postflight_actions/runiTunesHelper

The above is the dopey script that Apple made that simply launches the helper if a user is logged in. Why not also test if the target volume is the booted volume? I don't know. Seems a little lame to me. For our purposes just delete this file. For InstaDMG there is no need to kill the current helper and certainly no need to launch the helper inside the DMG you are building.