Experiments with AutoDMG, System Image Utility and OS version compatibility

SystemImageUtility_128.pngI use AutoDMG to build restorable system images for OS X, which uses a technique similar to System Image Utility’s NetRestore: run the OS X installer on one machine, but targeted at a disk image which is later converted to a read-only disk image, which can be restored to a Mac.

While running the 10.10.3 developer seeds on my build machine I noticed my AutoDMG builds seemed to never complete. After looking more closely at what processes were running, I noticed a suspicious process: /System/Library/Frameworks/Automator.framework/Versions/A/Support/update_automator_cache --system --force, which was called by a postinstall script in the com.apple.pkg.Essentials package. The process wasn’t actually hung – upon inspection using the opensnoop DTrace script, it was continuously re-indexing Automator bundles in an infinite loop.

Sometimes postinstall scripts have issues because there is a missing "$3" in a path, which would be substituted in with the target volume path. In my case, maybe this was just an issue with the beta version of the Automator framework. Here, the update_automator_cache process that’s trying to cache Automator bundles was the 10.10.3 seed version, not the 10.10.2 version that was actually being installed. It runs, however, chrooted in the volume being installed to, meaning it’s acting as though the installation volume is its root filesystem.

Because the issue seemed to be with this particular context of the OS installer, System Image Utility’s NetRestore image creation workflow exhibited the same issue. So, I filed a bug, but Apple closed it immediately due to my combining 10.10.3 tools with a 10.10.2 installer, which they claimed was unsupported. Of course, at the time there was no 10.10.3 installer available.

Yesterday (April 8, 2014) 10.10.3 was released, and I’m no longer able to reproduce the issue, and I was also able to still build a 10.10.2 image on a 10.10.3 host. Allister Banks gave some additional data yesterday, which was that he experienced the same looping process when building a 10.10.3 image from a 10.10.2 host.

What’s interesting is that Apple also just released a KB article which seems to detail my issue exactly in a succinct summary. They recommend always using the most recent version available, for “best results.” However the difference here is that they claim a 10.10.3 host can build “10.10.2 and earlier.” So the response I got in my radar might be not entirely accurate, but this is also confused by the fact that my earlier test was using the developer seed and not a released version.

My own summary is that while there might be aspects of SIU that change from minor releases, and that building an image from an installer source should usually work, if there are issues because of a bug in a tool that’s run in a postinstall script, or due to an incompatibility with versions of system frameworks being used in this context, there’s not much one can do except wait until the update is generally available and a new OS installer is available in the Mac App Store.

Tagged , , , , | Comments closed

Security Updates leaving mach_kernel visible

In the past, there have been cases where system updates for 10.8.5 (and possibly earlier versions) leave the OS X kernel (at /mach_kernel) visible to users in the Finder. This file has since moved to /System/Library/Kernels/kernel in OS X Yosemite, but previously to Yosemite it is located at /, and included in the package payload for system updates like OS X Combo/Delta and Security Updates.

OS X installers and updaters typically keep this file hidden in the Finder using a tool called SetFile, which is able to set miscellaneous file flags including the “hidden” flag. The Security Update 2015-002 for Mavericks, released on March 9, 2015, does not include any of the postinstall “actions” (miscellaneous scripts and tools executed by a master script) in the installer that were present in the 2015-001 update.

Comparison of SecUpd2015-001 and -002 installer scripts in Pacifist.

Comparison of SecUpd2015-001 and -002 installer scripts in Pacifist.

We have few admin users at my organization, but it has happened at least once that a curious admin user has wondered what this “mach_kernel” file is and moved it to the trash, only to find that their system volume will no longer boot.

Why does Apple continue to ship this bug when they have a knowledge base article on it?

Why does Apple not simply set the hidden flag in the file in the package payload, rather than depend on setting it according to a script? It is possible to set these flags on the file in a payload and not require any scripting to set a hidden attribute on a file.

We can fix this easily by distributing a script to clients that would do something like this:

if [ -e /mach_kernel ]; then
  if ! /bin/ls -lO /mach_kernel | grep hidden > /dev/null; then
    echo "Un-hidden /mach_kernel found, hiding"
    /usr/bin/chflags hidden /mach_kernel

While Apple’s acknowledged this issue given their knowledge base article, I still felt it’s worth opening a bug for.

1 Response

darwinup, Apple’s Darwin Update utility

Yesterday in ##osx-server, Pepijn Bruienne mentioned having stumbled upon an OS X system binary he’d never seen before, which was new to me as well: darwinup. This tool is used (or was used – public development of it seems to have stopped around OS X 10.7) for the purpose of managing versions of OS X system components by installing “roots” distributed in a variety of ways. It abstracts several different archive formats and wraps tools like curl, tar, rsync to perform its tasks.

It can install and remove packages installed via rsync-able locations and HTTP(S) URLs, and keeps track (in an SQLite database) of its activity and overwritten files such that it can roll back installations of system components to previous versions. I’ve seen it included on OS X systems as far back as OS X 10.7 (Lion) up through 10.10 (Yosemite). My immediate reaction was that this was like a basic package manager that’s included with every copy of OS X.

Digging a bit further, this tool is part of the DarwinBuild project, whose public development seems to have stopped around 10.6/10.7 (like most other macosforge projects). According to their notes, it is definitely not a package manager, however. These notes contain a much more thorough explanation of the tool than its manpage, so I’d encourage you to read through it if you’re interested in why the tool exists. The manpage has a few useful examples, such as installing components from Apple’s (similarly-abandoned) Roots repository. This repo of compiled OS X components was also completely news to me.

The darwinup tool obviously exists for testing and development purposes, so I would highly not recommend installing Apple’s old roots onto a system you care about, because they are now so outdated and could overwrite critical system components with incompatible versions. Of course, you can always roll back..

Here’s an example of installing compiled bootp tools from 10.7.2. You can also add additional -v options to print out more details about exactly what it’s doing with network and files-on-disk activity.

$ sudo darwinup install http://src.macosforge.org/Roots/11C74/bootp.root.tar.gz

A /AppleInternal
A /AppleInternal/Developer
A /AppleInternal/Developer/Headers
A /AppleInternal/Developer/Headers/BSDPClient
A /AppleInternal/Developer/Headers/BSDPClient/BSDPClient.h
A /AppleInternal/Developer/Headers/DHCPServer
A /AppleInternal/Developer/Headers/DHCPServer/DHCPServer.h
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Info.plist
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/MacOS/IPConfiguration
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Resources/English.lproj/Localizable.strings
U /usr/lib/libBSDPClient.A.dylib
U /usr/lib/libDHCPServer.A.dylib
U /usr/libexec/bootpd
A /usr/local/bin/bsdpc
A /usr/local/darwinbuild
A /usr/local/darwinbuild/receipts
A /usr/local/darwinbuild/receipts/bootp
A /usr/local/darwinbuild/receipts/fb5424a830958c1b4cc8191de7b8c6e9d31f1aaf
U /usr/sbin/ipconfig
U /usr/share/man/man8/ipconfig.8
Installed archive: 2 bootp.root.tar.gz

$ sudo darwinup list

Serial UUID                                  Date          Build    Name
====== ====================================  ============  =======  =================
2      17FEFDD5-E202-485A-B429-E5407881A845  Jan 21 11:33  13F34    bootp.root.tar.gz

Note that the build number is not that of the root that was installed, it’s the build of the currently-running system (10.9.5).

Now let’s run the bsdpc utility that was just installed into /usr/local/bin to display info about available NetBoot images:

$ sudo bsdpc
Discovering NetBoot servers...

NetBoot Image List:
   1. DeployStudio-10.10-1.6.12 [Mac OS X Server] [Install] [Default]

Again, use this with care. We can see that these bootp tools installed system components in addition to executable binaries (from a 10.7 system onto a 10.9 system), so this is just a demonstration of the capabilities of darwinup. Don’t do this at home!

Tagged , , | Leave a comment