Articles,OS X August 31, 2017 at 2:53 pm

UEFI, 10.13/APFS, and You(r Imaging)

Let’s discuss the basic input/output system for IBM PC compatible computing devices, aka BIOS. Wait, that’s not a good start, P.eople’t reM.ember C.omputer and I.nternet A.cronyms. Ok, EFI – that’s a thing that’s like BIOS, right? You can lock it, it makes sure all your most vital hardware components are attached, and on the Mac it even throws up a faux loginwindow if FileVault 2 is enabled.

(Paragraph-long parenthetical: We are going to stop calling it FV2 at some point and just let it own the ‘FileVault’ name, since we all know that’s what we’re talking about, right? FV1 mattered, but it sure didn’t catch on like its successor. FV1 was a neat parlor trick, like Time Machine doing hard links to :all_the_things:. Anyway.)

Although Apple always likes to implement things that would only make sense to its design/engineering/marketing departments, they still need to comply with the (U)EFI spec by having a partition available just for updating boot ROM, aka firmware. I’m a simple lad, so here’s the long ‘disambiguation’ section: EFI applied to the boot ROM chip has nothing to do with firmware on lots of other components jangling around in your Mac, like the TouchBar (running embeddedOS) or wifi controller, and removing the partition is pretty harmless pre-TouchBar because it only had been a staging area to apply an update.

TouchBar Macs came along and now we had A Problemâ„¢: part of the activation process of what the TouchBar is, which is to say an iOS device very similar to the Apple Watch, was now embedded inside that ‘invisible’ EFI partition on the ‘host’ Mac. OS updates also updated the eOS image living in that same EFI partition, which needs to stay in-sync: if you leave the EFI partition but upgrade the version of the Mac OS via imaging, you haven’t delivered the new eOS image to the EFI partition, and you’ll see a nice black screen with Apple logo while it reaches across the internet to grab it. Which you had better hope is available and no proxies are in the way and you have an active internet connection. (eOS activation servers may have been up the other day, but we couldn’t get that image downloaded, even after multiple attempts at internet recovery, because whatever server hosts eOS versions was down. All Friday. Thanks Obama!)

Now APFS is bearing down on us, looking pretty ominous on the horizon. I’ll love the day-to-day speed boost for common operations, and the promise of Time Machine (and Siracusa’s dreams) being fulfilled, but otherwise it’s a very ‘hold on to your butts’ moment. The tricky part of where EFI overlaps with a filesystem is the APFS driver – as announced at the WWDC session, it’s a filesystem-based driver so that they can modify the format in the future without hard-coding it into the boot ROM directly. This means your firmware needs to be able to 1. recognize the APFS container format and 2. look for the driver inline (I guess is one way to put it) with that APFS container/volume(s).

So how do we get the firmware updated so that a 10.13 APFS image can restore successfully? Well a technique made reference to previously by others including @jazzace and adapted by @bruienne and @bochoven is to grab the FirmwareUpdate.pkg out of the full OS installer app bundle, then make sure the tools and scripts are in place so that it is universal across all supported hardware. Here’s what you’d run at the commandline, assuming you have the High Sierra Beta app in it’s default location and munkipkg installed and in your path:

/usr/bin/hdiutil mount /Applications/Install\ macOS\ High\ Sierra\
/usr/sbin/pkgutil --expand "/Volumes/InstallESD/Packages/FirmwareUpdate.pkg" /tmp/FirmwareUpdate
munkipkg --create /tmp/FirmwareUpdateStandalone
/bin/cp /tmp/FirmwareUpdate/Scripts/postinstall_actions/update /tmp/FirmwareUpdateStandalone/scripts/postinstall
/bin/cp -R /tmp/FirmwareUpdate/Scripts/Tools /tmp/FirmwareUpdateStandalone/scripts/
munkipkg /tmp/FirmwareUpdateStandalone

And then it’s up to you to put it in your deployment mechanism of choice. Cheers!

Allister Banks

Allister lives in Japan, has not read the Slack scroll back, and therefore has no idea what is going on.

More Posts - Website

Follow Me:



  • So all the more reason to stop Legacy Nuke & Pave imaging entirely? Why bother? There is little need for it as you are not stripping out OS features or hobbling things that SIP should block anyway most of which can be scripted. Then installing Configuration Profiles, policies, scripts, Launchd plists and software can be done by the MDM. DEP zero touch is the way to go. I don’t see the point of imaging as there are so many new ways to enroll and deploy. Nuke a system before reassigning can be done with a USB3 installer jump drive and then thin provision the Mac installing all the security endpoints and software. Script things like removing GarageBand, etc.

  • I agree that it might be time to stop the Nuke and Pave Imaging, and moving to configuration profiles and package installers. Unfortunately, not everyone has a JAMF Pro Server, or even Munki, especially if you’re the little Mac guy sitting in a big Windows environment. I like to keep my options open, and the Big Windows guys like imaging. I’m a fan of the thin image, using AutoDMG. I like this article though, it’s good push the limitations of the new OS.

  • Would rather nuke and image! Easier to do labs if you still have them. Not everyone is BYOD or whatever. Feel more comfortable nuking as well as who knows what is shipping on the device. Usually a problem for HP, Lenovo, and other PC manufacturers, but has also happened to the iPod I believe at one point. Would rather have my image on it and customized and ready to go. Doing the thin imaging is so much more work and Apple doesn’t make it very easy making packages. I wish they would make a nice app to make packages again.

Leave a reply

You must be logged in to post a comment.