creating blank image with recovery partition on Sierra

[swright_mm]

I am trying to create an image using composer like i normally do. Usually I click the MacHD as well as the Recovery partition and create an OS package. Now everytime I do it I get this error.

"Failed to build DMG from volume /Volumes/Macintosh HD 1

Resizing to 14856055296 bytes and adding 1 partition
Started partitioning on disk3s2 Macintosh HD
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Macintosh HD appears to be OK
File system check exit code is 0
Resizing
Shrinking file system
Modifying partition map
A problem occurred; undoing all changes
Error: -69850: The chosen size is not valid for the chosen file system"

What changed in Composer that it now does not allow me to create the OS package? I am using Suite 9.97.

[MikeF]

I have found the same issue and what I had to do to get around it was not to include the recovery partition. Composer seems to have an issue getting that.

What I did was just capture the OS partition and them I used terminal to capture the recovery drive. trying to capture the recovery drive with composer always failed.

I used directions from this site to capture the Recovery Partition
https://www.lifewire.com/create-os-x-recovery-hd-on-any-drive-2260909

[easyedc]

Out of curiosity, why not AutoDMG? Composer seems to capture (what I assume) is the sleep image, which seems to add ~5.5GB to my base image. Using AutoDMG I usually come in much smaller and it captures the recovery partition. It allows me to drop in a few base items (Office Suite, our admin user, some printer drivers, etc) and is a never-booted image.

I've actually been tinkering with my base image recently and played with Composer to do it. Here's the same image, same base install

-rw-r--r--@ 1 xxxx xxxxx 8120319857 Jan  4 10:47 macOS 10.12.2 AutoDMG.dmg
-rw-r--r--@ 1 xxxx xxxxx 13912392704 Mar 16 16:30 macOS 10.12.2 COMPOSER BUILT.dmg

[swright_mm]

@easyedc The reason I use composer is because I like to set up the blank base image with a few settings and capture it that way. And Then I build out a user profile to attach to it when imaging. So normally it captures both partitions and then when using the imaging app it does both block copies and then the user profile.

[easyedc]

my base image built with AutoDMG creates a never booted .dmg which includes
- Whichever OS I'm building from including all patches since the OS build
- Recovery partition
- It installs an admin account (account created with createUserpkg)
- Hidden service account (same method)
- Flash/Java/Office suite
- Anything else I want via pkg
And then I have a first run script after boot that cleans up all the miscellaneous settings or gets managed by config profile.

Granted, we use target disk mode imaging over thunderbolt and image in just a few minutes versus a net restore image. But I believe it's easily converted over to a net restore image.

[AVmcclint]

I also just encountered this same problem on a new computer. The only thing that's different is all our other images were created from MBPs while this one is being made from a new MacPro. We need the Recovery Partition included since we are using FileVault. Capturing the Recovery Partition separately has never worked out for us. It actually looks like it fails on compressing the image. I would think it should still work, right?

[jwiswell]

So is the general consensus on this use AutoDMG instead of Composer?
(I'm running into the same issue trying to capture a 10.12.5 image using Composer v9.99)

Has anyone opened a ticket with support on the off chance this is something they need to fix in a future version?

[azaletel]

I'm getting that same error with Composer 9.99 and 9.98. Strangely enough, it worked fine for both a Mini and iMac that I imaged, but fails on a MacBook Pro.

[AVmcclint]

I discovered what I needed to do. First I tried using Create-Recovery-Partition-Installer and installing the partition after the computer has been imaged without a Recovery HD. This fails every time - apparently because of SIP. However, if I take the 10.12.5 Recovery HD package this app creates and I put it in the imaging Config with a Priority 2 (the Macintosh HD has a Priority 1), the package installs correctly since during Netboot, the local hard drive is not ruled by SIP. After booting up I verified via diskutil list that there is now a Recovery HD partition and when I enabled FileVault, it worked just fine.

It is very unfortunate that Composer can no longer capture the Recovery HD. That functionality was a welcome addition a few versions ago. There seems to be a lot of things in the macOS now that the Casper/JAMF tools just don't handle well any more. Are the JAMF devs not as close to Apple as they should be? (10.12.5 installer via Self Service anyone?)

[jwiswell]

@AVmcclint - So you captured just the OS Drive using Composer, and then used the Create Recovery Partition Installer to create a Recovery HD package and installed that package using Casper prior to booting to the local OS?

[AVmcclint]

Yes. Ultimately that is the process that worked for me. I had to make sure I set the OS drive with a priority 1 and the recovery HD package as a priority 2 in Casper Admin so that's the order they are installed during the imaging process. If you have any other packages set to install during imaging and they have a priority 1 or 2, you may want to adjust those so they go in after. Who knows, it may work regardless of the priority, but it just makes sense to lay down the drives in the right sequence.

EDIT: screenshot of my config

[jwiswell]

I agree, it does make sense to drop them in the correct order. I'm still muddling my way through managing all of this after abruptly losing my Casper Admin.

It's been interesting, to say the least, as I'm primarily a Microsoft guy.

I'm extremely thankful for this whole community as I'd have a very discontent and loud minority of users if it weren't for y'all.

[jwiswell]

@AVmcclint how did you manage to get the CRPI to create a 10.12.5 Package?

Mine keeps failing when I drag the installer over it.

[AVmcclint]

Interesting. I don't know. It just worked. Are you using the "Install macOS Sierra.app" downloaded from the Mac App Store? Do you have enough free space on your hard drive to store the resulting pkg? I think it's about 600MB in size. Are you getting an error?

[jwiswell]

@AVmcclint Yes I have plenty of space and am using "Install macOS Sierra.app" from the store.

I WAS getting an error yesterday.... just tried it again now (so I could see the error) and I THINK it worked.... SMH.

I'll update my Configuration to use the Composer plus this package and maybe now it'll work. Fingers Crossed!

[jwiswell]

It's working now that I've got a valid "RecoveryPartitionInstaller" package.

Thanks, everyone!

[cwaldrip]

This is maddening. I can't get CRPI to build an installer, I keep getting an error regarding cocoaDialog not found. Tested on a virgin machine running 10.12.6.

[irobinso]

I'm getting the same error as cwaldrip. Here's a screenshot:

[irobinso]

My previous comment is still awaiting moderation, but I was able to get this working after trying a few things. I had to run the RecoveryPartitionInstaller with root permissions via the Terminal. It looks like without doing that it didn't have write access when trying to download cocoaDialog.

I haven't tested yet to see if the package actually creates the partition as intended, but it did let me create the package.

[The_Lapin]

I had to do the same, running as root from Terminal, in order for Create-Recovery-Partition to work. Creates the installer package, and it shows as installing properly, however... Running diskutil list returns the following:

 #:                                         TYPE   NAME                    SIZE           IDENTIFIER
   0:      GUID_partition_scheme                                   500.3 GB   disk0
   1:                                           EFI   EFI                          314.6 MB    disk0s1
   2:              Apple_CoreStorage  Macintosh HD        499.3 GB   disk0s2
   3:                            Apple_Boot                                  650.0 MB  disk0s3

So the recovery partition is created but isn't being named, and FileVault still fails to start.

[frozzierox]

If you choose to use Composer to make the images (like i do), then you have to mount the RecoveryHD first and then capture it separately.

While on target mode, from the host:
1. Get the Recovery drive identifier by listing all drives

diskutil list

Output will usually look something like this:

JSS-BASE-3:~ admin$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            499.4 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3


/dev/disk2 (external):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         251.0 GB   disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:          Apple_CoreStorage Macintosh HD            250.1 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3

2. Now mount the appropriate drive (mine is always 2s3):

diskutil mount /dev/disk2s3

3. Using Composer, "Build OS Package", select the recovery HD only and create a new dmg package.
4. Create/update your configuration (in casper admin) to add a partition and use that new Recovery package you created.

Using the above method, I have no issues in enabling FileVault 2 and remotely locking macs (also needs the recoveryHD)

update: fixed up typo

[crbeck]

For anyone else that comes across this issue and wants to use Composer, if you capture the image from a 10.11.x machine then Composer will work. Even if the target machine/image is 10.12.x. There must be some issue with Composer and 10.12.x while capturing an OS image and attempting to resize partitions. Figured it out with an older MacBook Pro I use here for testing, it's at 10.11.6 with the latest security updates and using Composer 9.98.

[loza8454]

At The_Lapin

I'm also getting this. Were you able to resolved it.

Running diskutil list returns the following:

#: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 500.3 GB disk0 1: EFI EFI 314.6 MB disk0s1 2: Apple_CoreStorage Macintosh HD 499.3 GB disk0s2 3: Apple_Boot 650.0 MB disk0s3

[jreinstedler]

I discovered what I needed to do. First I tried using Create-Recovery-Partition-Installer and installing the partition after the computer has been imaged without a Recovery HD. This fails every time - apparently because of SIP. However, if I take the 10.12.5 Recovery HD package this app creates and I put it in the imaging Config with a Priority 2 (the Macintosh HD has a Priority 1), the package installs correctly since during Netboot, the local hard drive is not ruled by SIP. After booting up I verified via diskutil list that there is now a Recovery HD partition and when I enabled FileVault, it worked just fine. It is very unfortunate that Composer can no longer capture the Recovery HD. That functionality was a welcome addition a few versions ago. There seems to be a lot of things in the macOS now that the Casper/JAMF tools just don't handle well any more. Are the JAMF devs not as close to Apple as they should be? (10.12.5 installer via Self Service anyone?)

Worked for me - hopefully this can be fixed... running latest (9.101 as of now) made no difference and issue persisted when building on a MBP with TouchBar.

[RobertHammen]

Stop. Using. Composer. To. Create. OS. Images. It sucks at a lot of things, and this is one of them.

AutoDMG and the "Install macOS <name>.app" is all you need to create a never-booted, up-to-date OS. Want to change some settings? Figure out how to script them. Logging in even once introduces cruft into your booted OS image.

There are two kinds of people in the world: those that use AutoDMG, and those that eventually will.

[Chris_Hafner]

@RobertHammen Now I am very much a fan of AutoDMG... though Apple now seems to point users back to utilities like Composer (or SIU, DiskUtility, etc) for ReDeployment of 10.13 if I read their documentation properly. Thoughts on this?

P.S. Composer is great if you know what you're doing! It's like Little Snitch and Packages all wrapped into one!

[RobertHammen]

@Chris_Hafner There's a beta of AutoDMG for High Sierra which fully supports APFS.

AutoDMG for High Sierra

I use Composer to build packages, but then again, I have built probably thousands of packages in my day. The problem with Composer is when people "go nuts" and decide to snapshot all the things, and end up wrecking their OS. I guess any powerful tool has the potential to be misused... which is why I strongly recommend AutoDMG, as it pretty much does one thing, and does it very well...

[Chris_Hafner]

Agreed!