Though they position it as a tool to help with Thunderbolt/Firewire imaging, it actually is a more general purpose tool. My initial impression is that if you are building compiled Lion or Mountain Lion images, this tool could replace the use of InstaDMG or System Image Utility for many people.
Allen Golbig has an article on AFP548 on creating a package that will create or update a Recovery partition on a Lion or Mountain Lion volume.
The solution requires you get a few pieces from Apple:
- The BaseSystem.dmg and BaseSystem.chunklist from an InstallESD.dmg; found inside “Install Mac OS X Lion.app” or “Install OS X Mountain Lion.app”
- Apple’s Lion Recovery Update package.
Additionally, Allen’s solution requires the use of Joe Block’s The Luggage, which in turn requires Xcode (or at least the Xcode command line tools) and PackageMaker.
Since getting all of that running might be a nasty hurdle to jump for some, I’ve put together a package template you can use. It’s available here.
To use it, you’ll still need to obtain the dmtest tool from the Lion Recovery Update package and the BaseSystem.dmg and BaseSystem.chunklist from an InstallESD.dmg.
pkgutil --expand RecoveryHDUpdate.pkg ./RecoveryUpdate
cp dmtest /path/to/CreateRecoveryPartition.pkg/Contents/Resources/
hdiutil attach /path/to/InstallESD.dmg -noverify
cp /Volumes/Mac\ OS\ X\ Install\ ESD/BaseSystem.* /path/to/CreateRecoveryPartition.pkg/Contents/Resources/
hdiutil eject /Volumes/Mac\ OS\ X\ Install\ESD/
When you are done,
CreateRecoveryPartition.pkg/Contents/Resources/ should contain:
You’re done unless you’d like to edit the package identifier and/or version in CreateRecoveryPartition.pkg/Contents/Info.plist.
You can now use this package to install a Recovery partition (or update an existing partition).
Now that you can create an Installer package to install Lion or Mountain Lion, you have the possibility of using this package instead of an “image” to initially setup/configure a machine.
This may not be initially obvious.
If you’ve used InstaDMG or Apple’s System Image Utility to build a deployment image, you might notice that the components you use are very similar to the components you use to create a Lion or Mountain Lion installer package. Those components are:
- OS X installation media (usually an InstallESD.dmg)
- One or more additional packages to install after the OS is installed.
The difference is that InstaDMG “compiles” those components into a disk image that you “restore” to a target volume. System Image Utility can do that as well, or it can create a NetInstall workflow that just installs the components in order.
An advantage of the “compiled” disk image approach is speed. It’s much faster to restore a disk image to a target volume than it is to install the components seperately.
But there are advantages to the “install the components” approach as well:
- You can upgrade or reinstall OS X on a current boot volume without affecting user data. “Imaging” requires erasing the target first.
- Installing Lion or Mountain Lion causes the appropriate Recovery HD to be created automatically. If you use an imaging approach, you have create the Recovery HD separately; either by capturing and deploying an image of the Recovery HD, or using another scripted process to create it.
- InstaDMG and SIU generally limit you to building an image on the same OS; in other words, you can only build Mountain Lion images on a Mountain Lion machine, and Lion images on a Lion machine. createOSXinstallPkg allows you to create Lion and Mountain Lion installers on Snow Leopard, Lion, and Mountain Lion.
It’s possible to use DeployStudio to install Lion or Mountain Lion on a target volume using a package created by createOSXinstallPkg. You can upgrade an existing volume, or erase and install to an empty disk. Rich Trouton has documented these options:
Last fall, I released a set of tools I called “InstallLion.pkg”. The introductory post is here.
Now that Mountain Lion has been released, you may be wondering: “Can I use these tools to create a deployment package for Mountain Lion?” The answer is yes. InstallLion.pkg can be used to make an installer package for Mountain Lion.
But I have a better set of tools for you. Today I’m introducing
createOSXinstallPkg. This tool can be used to create installer packages for Lion and Mountain Lion and features many improvements over the “InstallLion.pkg” tools.
The first improvement: it’s much easier to use createOSXinstallPkg to create installer packages. With the old tools, you had to run one or two scripts — one to download an “IncompatibleAppList” package, and one to customize the InstallESD.dmg if you wanted to install additional packages along with the OS X install. And then you had to manually assemble the package, copying several components into the right places within a template package.
With createOSXinstallPkg, it’s as easy as:
sudo ./createOSXinstallPkg --source /Applications/Install\ OS\ X\ Mountain\ Lion.app
to create a basic uncustomized package that installs Mountain Lion.
But wait! There’s more!
UPDATE 18 July 2012:
Apple has re-added the iPhoto 9.1 and 9.2.3 updates to Software Update. This should fix the issue described below.
Recently on several mailing lists and on the #osx-server IRC channel on Freenode, people have been reporting issues with iPhoto 9.0, installed from the Apple iLife ’11 DVD or an disk image of the DVD, not showing any available updates from Apple Software Update.
Several of us looked at this issue yesterday on the Freenode #osx-server IRC channel and have concluded it is an Apple bug.
It appears that the only update for iPhoto 9 currently offered in Apple Software Update is the iPhoto 9.3 update.
There are two problems with this.
- This update requires Mac OS X 10.7.4. If you are running anything older, it will not be shown as an available update.
- This update requires iPhoto 9.1. If you are running iPhoto 9.0, it will not be shown as an available update.
For 10.7.4 machines, install the standalone iPhoto 9.1 update available from http://support.apple.com/downloads. The 9.3 update will become available. (Of course you could just use the standalone updates to update all the way to iPhoto 9.3.)
For machines running OS X versions earlier than 10.7.4, you’ll need to use the standalone updates available from http://support.apple.com/downloads to first update to iPhoto 9.1, then to iPhoto 9.2.3.
Starting with Xcode 3.2 on Snow Leopard, and installed by default on Mac OS X Lion are two new-ish packaging tools:
These tools are ideal for use in scripted package building, and can replace much of the use of the
packagemaker binary inside Apple’s PackageMaker application.
pkgbuild can be used to create simple flat packages.
productbuild can create more complex distribution packages, which may contain one or more flat packaged generated using
Check out the man pages for
productbuild for more info.
pkgbuild is very easy to use, compared to
packagemaker. There are two chief limitations that I found in attempting to use it as a replacement for
pkgbuildcreates only flat packages. These are supported only on 10.5 Leopard and newer.
- There didn’t appear to be a way to specify that a package required a restart or logout.
The first is not really a problem if you don’t have to manage any pre-Leopard machines.
The second can be worked around by using productbuild — the Distribution file can specify the need to restart. That’s the officially supported solution, but is a bit of a pain.
It turns out that
pkgbuild has an undocumented
--info option. This allows you to specify a PackageInfo template that can be used to specify some additional info that can’t be specified through other
If I create
/tmp/PackageInfo with these contents:
<?xml version="1.0" encoding="utf-8" standalone="no"?>
Then do this:
pkgbuild --info /tmp/PackageInfo --component /Applications/Firefox.app /tmp/Firefox.pkg
I get a package for Firefox that requires a restart.
See http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html for more info on flat package PackageInfo files, which are not the same as bundle package Info.plist files.
There is some concern that this relies on an undocumented option, which Apple could change or take away at any time — but they could do that with documented options as well…
The May 2012 issue of MacTech is available via the iPad app; dead-tree mailings can’t be far behind.
In this month’s issue I detail a method for creating packages to create a local admin account on your managed machines. This same package will create a working local admin account on Leopard through Lion (and possibly beyond), and will work in the stripped-down Lion install environment. If you need to update the local admin password, you can just install a newer version of the exact same package.
This fits in with my general theme for 2012: which is “Don’t Repeat Yourself!”
A new release candidate of the Munki tools is available here:
In my previous post, I provided a tool to enable you to check your collection(s) of packages to determine if any are affected by the Package Apocalypse.
But what to do once you’ve found packages with expired signatures? If Apple has provided an updated replacement package at http://support.apple.com/downloads/, it’s probably best to replace the package with the expired signature with the updated one.
But that might not always be possible — Apple has not provided replacements for every package that has been affected, or the replacement might not be practical to use.
Continue reading “Fixing packages with expired signatures”