NOTE: Casper Imaging 9.65 addresses this & as such the workaround is no longer needed.

As blogged before, a part of our Casper Imaging workflow involves partitioning the “Macintosh HD” for use with FSTAB.

Unfortunately, we have discovered an issue with Casper Imaging & Yosemite shipped Macs as these Macs come with CoreStorage enabled “Macintosh HD”.  This has been logged with JAMF as D-008217 & this post will be updated once resolved.

To get around this defect, I’ve written a little AppleScript app called “CoreStorage Revert” that you can get via a PKG from here. (NOTE: This is for CoreStorage volumes & not Fusion drives).

The PKG is meant to be added to an AutoCasperNBI created NBI, as it removes the com.AutoCasperNBI.CasperImaging.plist as “CoreStorage Revert” launches Casper Imaging itself.

For more details on the app, the why & some rambling findings, see below.

The Defect

When attempting to partition a CoreStorage volume via Casper Imaging, you’ll receive the below error:

My guess is that Casper Imaging is trying to try & partition the CoreStorage volume. Whilst Disk Utility.app allows you to add a second partition to a CoreStorage volume, via diskutil from Terminal errors with:

Error creating partition map: Placing a partition map on a Core Storage logical volume is not supported (-69671)

Oddly with Casper Imaging 9.32, the imaging workflow wouldn’t error but wouldn’t partition the drive either. However, the above error appears in Casper Imaging 9.6 – 9.6.2 (current version as time of post).

Attempts via Casper Imaging

My original attempts to workaround this defect involved adding a script to Casper Imaging. Scripts run via the Casper Suite have various parameters available, & $1 was my parameter of choice.

Running a script via Casper Imaging using $1 will return the mount path of the target drive (for example, /Volumes/Macintosh HD). Once armed with that I delved into the diskutil’s coreStorage commands:

Sadly, there is not an obvious “partition” command. Even in  diskutil’s undocumented CoreStorage commands.

So I tried deleting the existing volume using the “deleteVolume” command, & once deleted creating 2 new volumes using commands similar to that below:

This seemed to create the correct structure, as per the below:

Unfortunately, in restoring an AutoDMG created OS.dmg via Casper Imaging no “Recovery HD” was laid down.

Next attempt was to create 2 Logical Volume Groups with a single volume in each. 1st step in that is to delete the Logical Volume Group as per:

However, in running the below not only is the “Target Drives” mount point changed but it’s disk identifier is too. As Casper Imaging makes a note of these when a drive is selected & the imaging process is started, the imaging process would then fail.

But, if I created 2 Logical Volume Groups each with a volume which was named the same as per what the configuration expected. Then imaging went through fine if no partitioning or erase step was added,  with  the “Recovery HD” was correctly laid down on the “Macintosh HD” CoreStorage volume. It’s worth noting that using the createVolume command more than the 2 volumes that Disk Utility.app allows can be added to a single logical volume group.

This also wasn’t great for us, as when we image we erase the “Macintosh HD” & not the “Users HD” as this preserves the users data. But the above was destructive unless more logic was added.

What would Yosemite do?

If you’ve spent some time playing around with CoreStorage volumes, your probably asking why I faffed around so much & didn’t just run the below. (This command is non-destructive to the existing data & can be done on the fly).

/usr/sbin/diskutil corestorage revert $1

Well, I thought that CoreStorage was the new de facto that Yosemite required. Hence all the effort.

Turns out that not only did running the above command in a script via Casper Imaging have the same issue as mentioned above due to the disk identifier changing, it’s also not needed.

Also, if a Logical Volume Group contains more than one CoreStorage volume, then the revert commands fails with:

Error: -69745: This operation can only be performed if there is exactly one Core Storage logical volume present in the group

In taking this back a bit,  I updated an already partitioned 10.9 Mac to 10.10. After which the partitions were preserved in the original volume format.

So what would Yosemite to do non-CoreStroage enabled partitioned volumes? Nowt.

CoreStorage Revert.app

So all the above lead me to realise that I do not need to keep the volume as a CoreStorage volume & that I needed to make any changes to the target drive outside of Casper Imaging. Hence “CoreStorage Revert.app“.

The app itself is launched via the below LaunchAgent:

When installed as part of NBI creation through AutoCasperNBI, the LaunchAgent “com.AutoCasperNBI.CasperImaging.plist” is deleted from the NBI via the below “postinstall” script.

With all that in place, the “CoreStorage Revert.app” will run at login of the root user on the NBI. If a CoreStorage volume is detected, the below is shown.

Pressing “Revert” will revert the volume as shown in the dialog from CoreStorage to a normal volume, once reverted Casper Imaging will launch. After which “CoreStorage Revert.app” will quit.

If no CoreStorage volumes are found, or if  “Skip” is pressed then Casper Imaging is launched & “CoreStorage Revert.app” then quits.

For completeness sake, the app is below:

Going Forward

It’s obvious that this non-standard setup we’re plodding along with is going to need to stop. With projects looking at both FV2 encryption & user backups, I figure we’ll go to a standard setup once those are landed.

Also, with the issues highlighted above, i’m unsure how JAMF will implement managing multiple “partitions” & CoreStorage volumes. However, I hope to be on a beta to find something that works for us & others.