Wiping partitions prior to imaging

Valued Contributor II

I was having issues with 10.8 Netboot shadow files jumping up to 1-2 gigs each - so a user in the this post helped me to use local RAM for shadow files which helped server space issue that I was having. https://jamfnation.jamfsoftware.com/discussion.html?id=6443

We prefer to wipe the Recovery partition except where FileVault is required. However, since migrating to 10.8 Netboot and making this local RAM change, we are getting a large percentage of ""Error: -69888: Couldn't unmount disk"" when wiping partitions (15-20% of machines imaged getting this error).

We used this script with great success the last few years - only getting this error maybe 2% of the time using 10.7 netboots

# Partition Disk to 1 partition and format
echo "pre-action:STATUS:Setting Disk to 1 HFS+ Journaled Partition"
diskutil eraseDisk "Journaled HFS+" "Macintosh HD" /dev/disk0

When the errors started coming on a large % of our imaged machines, JAMF had me try this script, unfortunately same result

set -x 
# Partition Disk to 1 partition and format
# count the partitions on the system
count=`diskutil list | grep Apple_HFS | wc -l`
if [ $count = "1" ]; then
echo "Count = 1"
diskutil eraseDisk "Journaled HFS+" "Macintosh HD" /dev/disk0
set +x

Both scripts present the same types of errors "Error: -69888: Couldn't unmount disk" which I assume is some timing issue due to now using local RAM disk.

We do a mass imaging every summer when we do a mass purchase, so none of my computers right now extra partitions prior to imaging (partition already wiped July 2012), so I can't answer if the error actually means partitions aren't getting wiped until we do a mass purchase this July. I've tried putting partitions back and reimaging but so far haven't gotten the error on those machines (guess I'm lucky)

Anyone had this issue? We use a firmware password so it's not an emergency issue but we'd like to try to get the issue under control if we can.

I keep hoping for JDS to take place of Netboot (and maybe this issue goes away), but I'm running out of time to really stress test that prior to our summer reimage in 3ish months.


Valued Contributor

What sort of machines are giving you the error? Might they already be encrypted, or have Fusion drives? The reason I ask is that reference to disk0. If you're using CoreStorage, your main partition isn't on disk0 (it would be disk1 if you FileVault, or disk3 if you have a FusionDrive - most of the time).

Valued Contributor II

Mostly older macbooks, have also seen it with macbook airs. None have encryption on.

Valued Contributor

Hi Sally, Did you select; x Erase "Macintosh HD"

with Casper Imaging? If not please select it and see.

This is my Script

Script to delete all partitions. Must run this with script priority set to "Before" imaging

# this assumes that /dev/disk0 is going to be the main HD in all systems
# Script priority in JSS should set to "Before" as this need to be done before Imaging
/usr/sbin/diskutil partitionDisk /dev/disk0 1 GPTFormat jhfs+ "Macintosh HD" 100%
echo "Disk0 has been re-partitioned."

exit 0

Script to erase Recovery partition. Must run this with script priority set to "At Reboot"


# Erase the Recovery HD partition and format it with HFS+ and rename it to "ErasedRecovery HD"
/usr/sbin/diskutil eraseVolume HFS+ "ErasedRecovery HD" /dev/disk0s3

# Unmount the "ErasedRecovery HD" partition
/usr/sbin/diskutil unmount /dev/disk0s3

# Make the "ErasedRecovery HD" partition a Apple_Boot partition and will automatically get hidden
/usr/sbin/asr adjust -target /dev/disk0s3 -settype Apple_Boot

exit 0