Using bootstrappr to build testing VMs with VMware Fusion

As part of my preparation for next week’s WWDC conference, I’ve been working on ways to build virtual machines using VMware Fusion for testing. In previous years, I have used NetBoot-based solutions to help me with this process. With NetBoot going away though, I’ve started using bootstrappr as my replacement deployment tool.

Bootstrappr is designed to install packages and scripts, but in my case I’m having it install only one package: a firstboot package created by First Boot Package Install Generator.app. The firstboot package in turn installs a set of installer packages to configure the VM and install the software I want. For more details, please see below the jump.

First Boot Package Install Generator.app now adds product identifier tags to its packages

As a follow-up to Greg Neagle’s discovery that product identifiers are now needed to ensure best results when adding additional packages to macOS High Sierra OS installers, I’ve updated First Boot Package Installer Generator.app to add product identifiers by default to the firstboot packages created by this tool.

The product identifier values will be the user-selected Package Identifier followed by the Version Identifier.

These values will appear in the firstboot package’s distribution file as shown below:

For those who need this capability, an installer for First Boot Package Install Generator.app 1.7 can be downloaded via the link below:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/releases/tag/1.7

Apple Setup Assistant and First Boot Package Install Generator.app

A while back, I built an Automator application named First Boot Package Install Generator.app. It’s designed to generate installer packages, where the generated packages in turn serve as a delivery mechanism to enable other installer packages to be installed when a Mac boots up.

As part of the process of installing the other installer packages, an application named LoginLog is supposed to open over the login window and display a log of what actions are taking place, what is being installed and whether that particular installation succeeded or not.

For the most part, this process of launching LoginLog and displaying the log works as designed but it was brought to my attention that there was one scenario where LoginLog did not appear as expected. When a firstboot package created by First Boot Package Install Generator.app was installed onto a new installation of OS X El Capitan, LoginLog did not appear over the Setup Assistant.

The reason it didn’t appear is because the LaunchAgent for LoginLog is triggered by the Mac being at the login window.

However, Apple’s Setup Assistant on El Capitan no longer runs over in the context of the login window. Instead, it runs in the context of an account named Setup User.

In order to have LoginLog appear again in this scenario, I needed to develop a method which could accomplish two tasks:

1. Suppress Apple’s Setup Assistant during the time when I wanted the LoginLog application to appear.
2. Avoid interfering with an otherwise desired launch of the Apple Setup Assistant.

For more details, see below the jump.

Automator’s Ask for Finder Items windows no longer showing text prompts in OS X El Capitan

As part of working with Automator to build applications, I’ve been leveraging the ability of Automator’s Ask for Finder Items action to set text prompts in my Automator-based applications.

These text prompts are included in the appropriate Finder windows and have been an easy way for me to set a particular message in an Automator selection window.

I recently noticed in OS X El Capitan that these messages no longer appear, which is a bit inconvenient as it leaves users of my applications with no clear direction as to what to do when this window appears.

 

It does not appear that AppleScript is affected by this issue, as the comparable AppleScript function properly displayed the desired text in both Yosemite and El Capitan.

As a workaround to keep my applications’ users informed on what to do, I’ve set standalone AppleScript notifications to appear in my Automator applications before the Ask for Finder Items Automator action’s window.

All three of my Automator-based applications have now been updated with the workaround:

• First Boot Package Install Generator.app
• Payload-Free Package Creator.app
• Simple Package Creator.app

 

I’ve filed a bug report with Apple on this issue. For those interested in duplicating this, it is bug ID 23688457. I’ve also cross-posted the bug report to Open Radar, so the bug report details are available from the link below:

https://openradar.appspot.com/23688457

First Boot Package Install Generator.app

With the release of Yosemite, Apple has apparently made an undocumented change to the way it allows packages to be added to the OS installer. If you add any additional packages for installation as part of the OS install/upgrade, they must all be distribution-style flat packages. You can convert a component flat package to be a distribution-style flat packages by running the command below:

productbuild –package /path/to/component.pkg /path/to/distribution.pkg

This change is a problem for First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg, as they are both built as a bundle-style package and not as flat packages. While both First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg run fine on Yosemite, they cannot be added to customized NetInstall images created with System Image Utility or to createOSXinstallPkg-built Yosemite OS installer packages.

  

To address this issue, I’ve developed First Boot Package Install Generator.app, an Automator application that will allow the selection of a folder containing installer packages and then generate a distribution-style flat package that enables the selected packages to be installed at startup. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be used as part of a createOSXinstallPkg deployment workflow. See below the jump for the details.