The writing seems to be on the wall for InstaDMG. Even though Allister Banks has done a great job keeping the code up the last few years, people are clearly moving on to other tools, especially as they change their workflows from image-centric to installation-centric. As announced on AFP548 previously, Per Olofsson has released a tool that is reminiscent of InstaDMG but with a nice GUI on top: AutoDMG. For those who have an InstaDMG/InstaUp2Date workflow and fear that it might break soon, I have good news: you can use your current InstaUp2Date catalogues and the new AutoDMG to give you a solution that should work for some time to come.
If you are unfamiliar with AutoDMG, think of it as a drag-and-drop version of the original InstaDMG (i.e. pre-InstaUp2Date). Grab your OS installer and drop it on. Let AutoDMG grab any system software updates for you. Gather your software installation packages and drop them in the additional packages list. Then tell AutoDMG to build it. That’s it.
But, of course, if you have been using the InstaUp2Date add-on, you will have many lovely catalogue files that organize your various builds. AutoDMG does not yet have an ability to have pre-arranged sets or installation groups — you need to set up the desired build from scratch every time. The good news is that AutoDMG will accept the symlinks that InstaUp2Date creates after each run (located in the InstallerFiles/CustomPKG folder within your InstaDMG folder structure). So, in theory, you can continue to maintain all your catalogues, process them with instaUp2Date.py, then drag all those newly enumerated installer links into the AutoDMG Additional Packages list and build your image from there.
What you need to adjust
“In theory.” There are some things that you need to adjust (on both ends) to make this work. At this time, AutoDMG just installs packages. You cannot use disk images (that act as a wrapper for either a package or an app) as you can in InstaDMG. So you need to go through your InstaUp2Date catalogues and replace those disk image references with actual packages (i.e. mount the disk image in question, copy the package into the InstaUp2DatePackages folder, checksum the package and then use the generated text line to replace the old one.) Thankfully, packaging standalone apps that sit on a disk image (e.g., Firefox) can be almost as easy with the free Packages app. Mount the disk image, drag-and-drop the app onto Packages and it will create an installer package for you. Move the package into the InstaUp2DatePackages folder, checksum the package and change your catalogue accordingly.
The second thing you need to adjust is the catalogue that specifies which OS and set up of Apple updates you are going to run. AutoDMG takes care of that, so simply comment it out or remove it completely. Likewise, the instaUp2Date.py is expecting an OS, so you need to comment out lines 674–688 (“find the OS installer disc”) from the script. Note that AutoDMG does not automatically install Java (6 or 7), so if you need it, you’ll need to either add that manually to AutoDMG or add another line or two to one of your catalogues (I ended up making a standalone Java catalogue file and referenced it via Include in my main catalogue).
Thirdly, if you are accustomed to running InstaUp2Date with the -p option, you’ll either need to stop doing that or comment out a few more lines in the instaUp2Date.py script (lines 703–709 should do it, but I haven’t tested it).
Finally, depending on how large your payload is, you may come up against a limitation hard-coded into AutoDMG. While the sparseimage disk size in InstaDMG was set to 300 GB (which could be altered by changing the value of a defined variable), the default size in AutoDMG is 32 GB. If you need larger than that (which I do), then you need to go into the application bundle and find Contents/Resources/installesdtodmg.sh. Open the file and find this line of the script (about 90 lines into the current version):
hdiutil create -size 32g -type SPARSE -fs HFS+J -volname "Macintosh HD" -uid 0 -gid 80 -mode 1775 "$sparsedmg"
Change “32g” to whatever value you see fit. Save the file and you are ready to roll.
As with InstaDMG, AutoDMG requires that you be running the major OS that you are trying to build (i.e. if you want to build a Mavericks image, then you have to run AutoDMG while booted into Mavericks). However, there is no such limitation with InstaUp2Date in this context, since you are just using it to check the validity of your packages and organize the packages into the order that AutoDMG will install them. Feel free to keep InstaUp2Date running in just one OS and create as many OSes (real or virtual) as you need to run AutoDMG, accessing the same packages.
Also understand that Per’s intent for this tool was to build small common images (you may know them as “thin”) in a straightforward fashion. There may be features added later like parsing packages from disk image wrappers and saving build sets, but the likelihood of any particular feature being added is directly related to how much time it will take and how much it fulfills the intended mandate. For now, using your existing InstaUp2Date catalogues is the best way to automate what AutoDMG produces.
I’ve successfully built two images now with this InstaUp2Date + AutoDMG combination, both with over 130 “additional” packages. AutoDMG even ended up detecting an installation problem with one of my packages that had failed silently when it ran under InstaDMG. Unless someone else finds some gotchas along the way, I think the time has come to thank the originators and maintainers of InstaDMG for bringing us towards more modular deployment methods and retire the bash script known as InstaDMG.
InstaDMG is dead. Long live InstaDMG (a.k.a. InstaUp2Date + AutoDMG)!