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.
Final tips
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)!
Anthony Reimer
Anthony has been supporting Macs at the University of Calgary (Canada) since 1996, specifically the labs for the visual and performing arts. He is a musician and teacher by training, using those skills to conduct a community concert band and to give presentations on technology.
Follow Me:
by 
Per Olofsson reports that templates (meant to replace catalogues) should be a part of the next major release of AutoDMG. (https://twitter.com/magervalp/status/424085027228745728)
Version 1.4 of AutoDMG now has virtually every feature that InstaDMG had and a few more! I’ll submit another article once I’ve worked with AutoDMG for a while, but the writing is not just on the wall, the wall is the Berlin Wall ca. 1989. AutoDMG is feature-rich and should be the first tool Mac Admins look at if they need to build an image for deployment.
Its been a year, got an update?
I’m about to jump back into mac imaging after nearly 6 years absence. Your opinion and suggestions are greatly appreciated.
In general, the move to what I called “installation-centric” methods in this article is even stronger. If I were starting from scratch right now, I would see if my setup was suitable for Install-Only deployments, even if I was nuking and paving regularly (as you might in a educational computer lab). But there are still some reasons why you might choose to create a larger modularly-created image and AutoDMG is the tool of choice for most who go that route. Since you have the background, it’s probably worth watching my talk from Mac Admins @ Penn State from 2014 on the state of modular imaging and advanced AutoDMG techniques, which is helpfully linked on the AutoDMG home page. The only update to that talk is that I have thinned my image even more than described in the talk (moving more installers to the customizing phase) and have incorporated AutoPkg(r) into my workflow (which is the replacement-on-steroids for InstaDMG’s ability to specify a URL for downloading rather than an already-downloaded package).