We’ve recently gotten a few of the new 2015 Macs, specifically the new MacBook Airs and 13″ MacBook Pros. These models have new builds of 10.10.2, and won’t boot from our current NetBoot/DeployStudio Server.
While there are ways of capturing the hardware-specific OS so you can use it with AutoDMG and to create NetBoot sets, usually what we do with new hardware like this is employ a “no-imaging” process: we boot the new machine in Target Disk Mode, attach it to another Mac, and install some “bootstrapping” packages on the new Mac. For us, that’s four packages:
- A package to create a local admin account
- A package to disable the Setup Assistant
- The Munki tools package
- A package to put Munki in “bootstrap mode” on first boot.
Once these packages are installed on the new machine, we shut it down, connect it to the network, and start it up. Munki takes over and installs everything else we need.
This approach has worked well for us in the past with new hardware, and allowed us to deploy new hardware to users much faster than if we had to build hardware-specific NetBoot and AutoDMG images.
But these new 2015 Macs were throwing us a curve ball. After using Target Disk Mode to install the packages, upon reboot the Macs were refusing to boot, or booting very slowly. A check with Disk Utility claimed the startup volume had unrepairable filesystem corruption, and advised us to back up any user data, format, and re-install.
We saw this behavior on multiple new 2015 machines. Two things that stood out to me:
- The new machines all ship with an unencrypted CoreStorage volume as their main system volume, and
- We were connecting these machines (in Target Disk Mode) to a Mac running Mavericks (10.9.5).
My theory was that there is a bug causing the Installer on Mavericks to do something “wrong” when installing to a Yosemite CoreStorage volume that led to file system corruption.
I did not have the time (or desire) to get to the bottom of this issue; I needed to find a successful procedure for getting these new 2015 Macs to build. I found two.
First one: after starting the new Mac in Target Disk Mode, connect to another Mac running OS X Yosemite 10.10.2, and install the bootstrapping packages.
Second one: Boot the new Mac into the Recovery partition. Connect a USB drive (a flash stick will do) containing the bootstrapping packages. Open the Terminal from the Utilities menu and use the command-line installer to install the bootstrapping packages onto the main partition.
With either method, things proceeded normally and there was no filesystem corruption.
UPDATE: after seeing some reactions to this post on Twitter, until we understand more about this issue, I’d recommend using the second approach (via Recovery partition) — it’s possible this is more about Thunderbolt/Target Disk Mode than it is about 10.9 vs 10.10.
I hope this saves others some time and headaches.
8 thoughts on ““Building” 2015 Macs”
This happened to us when Mavericks rolled out and we got caught with our pants down… Same situation, new mac’s would roll out with whatever interim version of the OS apple rolls out with… and we needed to push packages to bring them up to speed with our other deployments…
Now for Yosemite I just use a flat image with OS X 10.10.2 + FileWave Agent and KACE Agent (don’t ask…) and we boot the new Mac’s in Target mode and image them via Thunderbolt using either Disk Utilities or a free tool FileWave has for Imaging Mac’s called Lightning (http://downloads.filewave.com/lightning/FileWave_Lightning-1.6.dmg). For some reason DiskUtilities takes about 3.5 minutes, but when we do this via Lightning it only takes about 2:38 seconds to do so, and you don’t have to deal with all that altogether.
Just a thought, and thanks for sharing…
“Imaging” via Thunderbolt is great, but you still need an image. Creating an image for these new machines with hardware-specific builds is a pain, and I don’t like doing it for a handful of machines, especially when 10.10.3 seems to be imminent.
Certainly there are many ways to get to the desired end-result. My post was intended to help people using a workflow similar to mine.
bootstrapping you say, really interesting. Is there any documentation on how to do this anywere? Or examples? Would love to try this out..
If you have been using a “thin imaging” workflow, where the image is just the OS plus enough additional pkgs to get your management system running (Munki, Puppet, Casper, Absolute Manage, FileWave, etc), then this workflow skips the part where you install the OS (there’s an OS already there!) and just adds the extra packages needed to get your management system running.
Once your management system is running, _it_ installs/configures the machine.
any new machines shipping with 10.10.1 or later (most new machines since february?) have been shipping with the what appears to be an almost ready to go FileVault configuration. In the initial setup assistant you get to choose to turn OFF filevault. The default answer is to leave it on.
if you choose the default answer, the setup assistant proceeds rather quickly. if you choose to turn it off, then it takes about 3 minutes of beachball, to proceed to the next step.
This is the CoreStorage volume I mentioned. Enabling FileVault encryption on such a volume is faster (and doesn’t require an additional restart) than it would be if the volume was a classic/native/old-fashioned HFS+Journaled volume.
I had this exact on issue on 2015 13-inch retina MacBook Pro. I believe the error reported by Disk Utility was invalid node count. I managed to fix the filesystem with several passes of Alsoft’s DiskWarrior
I wonder wether the filesystem was corrupted from factory.
Somehow my startupscripts wont work on 10.10.3, they work great on 10.10.2. Its the exact same scritps (launchDaemons and script). Is there a change in 10.10.3 on this? Its hard to troubleshoot since it wont show up in the logs?
Comments are closed.