We recently had to come up with an alternate solution to automate including the recovery partition during the imaging process. After a version upgrade of the JDS, JSS along with OS versions of our Mac Servers (now on Yosemite with Server app version 4.1) we found that the recovery partition on our standard image was not being included. So until that is addressed, we've added the recovery partition as a separate package installation for the imaging configuration along with a partition task. Works fine. However, what's been happening is that instead of the recovery partition size only being about 650 MBs as it should be, it's using 12.5 GBs on a 250 GB drive and 50 GBs on a 500 GBs drive. The partition task in the imaging configuration is specifically set to only utilize 1 GB for the partition with a maximum percentage set at 1% of the target drive. Everything looks fine and the source DMG image of the recovery itself is only 650 MBs when mounted. Not quite sure why the expansion occurs during the process. It's not terrible, but it is a considerable waste of drive space ultimately. Any suggestions?
Recovery Partition Size
+3
+18If you use autodmg to create the base OS image it will create the recovery partition for you.
+8I had the same issue.
To solve it I used Create Recovery Partition Installer
Then I moved to the same solution @davidacland mentioned, AutoDMG.
+3Thanks for the input and suggestions folks but our image already has the recovery partition. It was successfully being applied during the Casper Imaging process until we bumped up the JSS and JDS to a newer version and bumped the Mac NetBoot servers to Yosemite. I've used AutoDMG before and the Recovery Partition Creator script before. That's not what we need to solve in my environment though. The recovery partition portion of our base image is being (for lack of a better term) stripped out of the during the NetBoot / Casper Imaging process and only the primary OS partition and EFI partitions are created. We have solved that by adding a standalone recovery partition package and adding a partition task to the imaging configuration.
The problem is that the recovery partition is expanded during the process and using 25 to 50 GBs instead of 650 MBs.
After our JAMF rep solves our current issue, I'm sure this will not be a concern but right now we need to automate the recovery partition process for our field techs and we do have a solution that works. Just one that for some reason is using up excessive disk space and we cannot figure out why. The server settings for the partitioning task are in the screenshot above.
+22@RandallKS out of curiosity, what version of the JSS you are using, 9.72? What version of Casper Imaging are you using when you image the computer?
+39.62 for the JSS, JDS and Casper Suite. I know that is not the most recent version, which is 9.72. We plan to move to that version, however, it was our last upgrade from 9.3 to 9.62 that resulted in an entirely new set of operational problems for my environment, so next time we are not going to be so quick to upgrade again. There is too much of a risk of the existing operational problems remaining after the upgrade while introducing new ones. I'm not a big fan of "upgrade to the latest version in order to fix everything" as a first solution. That usually does not work in my experience.
+22You might want to try Casper Imaging 9.72 with your 9.62 JSS and JDS to see if the bug you are seeing is being caused by the Casper Imaging 9.62. I know they used to say to make sure the Casper Imaging matched the version of the JSS you are running, but recently my TAM told me it is generally fine to use a newer version of Casper Imaging with an older version of the JSS. I've also seem other people mention on other threads of using a newer version of Casper Imaging with an older JSS specifically because of some issues with older versions of Casper Imaging and 10.10 NBI. Have a look at the thread over here. There are some folks that mention using Casper Imaging 9.65 with 9.62 to get block copy to work.
+3Great suggestion buddy. We'll give that a shot. I seem to recall hearing the same thing regarding using newer versions of the Casper Imaging app with earlier versions of the JSS. It's definitely the block copy that fails and causes this. Thanks again.
+5While, i know this doesn't help much, but seeing the same issue. Tried using different version of Casper Imaging, but the same result (using JSS 9.72).
Just logged a call with Jamf.
+5Please see response from Jamf, about to test
This issue is known to us as defect D-008377. From what I can see in our system this should be resolved in the next release. Please have a look at the release notes when it goes public. The solution for this at this moment would be to use casper imaging 9.61 when imaging and creating a Recovery partition.
+5Tested, going back to Casper Imaging 9.61 and creating the recovery partition with Composer 9.61, fixed the problem.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.