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 C.an’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.

https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Single/2012-05-21#/media/File:Final_Trophee_Monal_2012_n08.jpg

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\ Beta.app/Contents/SharedSupport/InstallESD.dmg
/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!

About Allister Banks

Allister has had the honor of writing a book with Charles Edge (http://url.aru-b.com/packtbook), an article or two for MacTech Magazine, and speaking at conferences like MacAdmins Conference at Penn State. He lives in NYC, contributes to various open source projects, and speaks enough Japanese to order food.

Tags:

1 Comment

  • 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.

Leave a reply

You must be logged in to post a comment.