Monthly Archives: May 2015

Installing VMWare Tools on a Netboot NBI

Netboot is great.  VMWare Fusion is great. Yosemite is….Netboot and VMWare are great. I use VMs to test things on our builds at work.  To get those VMs setup I use our imaging process that utilizes Netboot.  However, I discovered that, new with Yosemite, when the VM Netbooted to our Yosemite NBI I wasn’t able to login to OS X. After typing in the username and password the login attempt would just hang with the spinning gear turned beachball.  No bueno. Turns out all it requires is getting the VMWare Tools installed on the NBI.  No problem right? But VMWare’s installer (read: .app) doesn’t allow installing on a non-boot volume.  Crap.  This wouldn’t be a very interesting post if we stopped here so…

TL;DR: you need to mount the NBI and install the tools via the CLI ‘installer’ command.

First, make sure that your existing NBI is read/write when mounted.  In my case the NBI is actually a .sparseimage but renamed to .dmg for Netboot use.  When mounting the image named .dmg it mounts as read-only.  Renaming the .dmg to .sparseimage mounts the volume as read-write. YMMV. There are ways to convert disk images to read-write. I’ll leave that discovery up to you if your environment requires it.

VMWare Tools acquisition/installation:

There are a couple ways to get the tools.  I prefer to pull the tools from the VMWare bundle itself to guarantee that the version of VMWare Fusion you’re running is compatible with the tools. If you want an automated way using AutoPkg to get the latest tools check out Rich Trouton’s post at Der Flounder.  You can also download the tools if you know what version you need at VMWare’s repository.

Locally, the tools are located in the application bundle found at /Applications/VMware\


Mounting that image results in the installer and uninstaller.


However attempting to use the .app installer will fail as it won’t let you target the install on a non-boot drive.  Since it’s a .app “installer” there must be a .pkg buried in the bundle. To get the actual installer .pkg right click on “Install VMWare” and choose “Show Package Contents”.  Navigate to the /Volumes/VMware\ Tools/Install\ VMware\ directory.  There you’ll find “VMWare Tools.pkg”. Jackpot.


Copy the “VMWare Tools.pkg” to the computer where the NBI is mounted and run ‘installer’ pointing the target at the mounted Netboot NBI.

 sudo installer -pkg /Volumes/VMware\ Tools/Install\ VMware\\ Tools.pkg -target /Volumes/Yosemite\ NetBoot -verbose

That will install on the mounted volume.  Once complete, unmount the NBI, rename it if necessary, and you should now be able to log into a Yosemite NBI when Netbooted in VMWare Fusion.

Tagged ,

Using pkgutil To Adjust Flat Packages

“I love it when companies break away from the standard pkg practices.”

– No one ever

When you run into an installer that is doing something you don’t expect or recommend we get to put on our Mac admin spelunking hat to dive into the depths of the installer to see what’s going on.  There are some handy tools that make this easier already bundled in the OS.  Those are: pkgutil and installer.  There are also good 3rd party apps like Pacifist and Suspicious Package that I use for examining installers as well.  For this exercise I didn’t need those.

I ran into an issue with the Fiery E-22C driver installer from EFI launching an app mid-install to offer to setup printers.

Not Helpful

That’s great for home users with a Fiery front end (who doesn’t have a Fiery at home?) but not for deploying in the enterprise.  The only way to get the drivers to install at this point was to click the link in the bottom left of the app window.  Not ideal. I tried many ways to bypass the “wizard” app as the installer existed but even when attempting a CLI install it would launch the app when a user was logged and the install would totally fail if no user was logged in.

One thing going for us at this point is the pkg is a flat package. Running the following will extract the pkg to better examine it:

pkgutil --expand ~/Desktop/Fiery\ Printer\ Driver.pkg ~/Desktop/fieryprinterdrivers

Navigating to ~/Desktop/fieryprinterdrivers shows us the expanded package contents:

Expanded Package

 Right click on the “FieryPrinterDriverInstaller.pkg” and choose “Show Package Contents”:

Show package contents

After digging around the piece that needed adjustments was the postinstall.  There was a system version check in there to launch the “wizard” if the OS was 10.5 or older.  If 10.5 or older it would just install the drivers.  That’s what I wanted on my new shiny OS!

#Pkg installs driver and exits in 10.5 since no Wizard is supported below 10.6
if [ "$MAJOR" = "10" ] && [ "$MINOR" = "5" ]
 logger "Postinstall Script: Checking for previous driver and printers with FSU and performing system cleanup"
 /bin/sh /tmp/efi_wiz_fsu_delete && logger "Postinstall Script: FSU done"
 sudo rm -f /tmp/efi_wiz_fsu_delete
 logger "Postinstall Script: Installing driver only for 10.5" && sudo installer -pkg /tmp/Fiery\ Printer\ Driver\\ Software/OSX/Printer\ Driver/OSX\ installer.pkg -target / && exit 0

Further down if the OS was > 10.5 it would launch the “wizard” which is what I didn’t want.  To fix this install postinstall script all I needed to do was remove the OS Minor version check to make it just install the drivers if the OS Major version is 10.  I can handle deploying the drivers to the appropriate OS so I’m not worried about using their logic.

if [ "$MAJOR" = "10" ] && [ "$MINOR" = "5" ]
if [ "$MAJOR" = "10" ]

Once the postflight file is adjusted we can flatten the package back up again by running:

pkgutil --flatten ~/Desktop/fieryprinterdrivers/ ~/Desktop/Fiery\ Printers\ Driver\ Fixed.pkg

 And now I have a new package “Fiery Printers Driver Fixed.pkg” that’s deployable, won’t launch the wizard, and will install the drivers.

fixed pkg is a pkg

Tagged ,