Reinstalling macOS on a MacBook Air with a T2 chip with no OS and external disk booting disabled
A colleague at work recently asked me to look at a MacBook Air A1932 model which wanted to have macOS reinstalled. This is usually not a complicated task, but the state of which this device was in was quite interesting and turned out to prove much more challenging, going down a rabbit hole of errors and conflicting information. Let me share with you the story of this MacBook Air and how I eventually got macOS running on it again.
Investigation/analysis of the issue
Let me first provide a summary of the device and scenario:
- The specific model is a MacBook Air Late 2018 (A1932). It was one of the first models to use the T2 chip when first released.
- A reinstall of macOS required to refresh the system.
- No existing macOS operating system present on the system disk (this was cleared before I received it).
- Booting from an external disk i.e. USB is disabled. That is going to be an important issue later.
The device itself was functional (as in powered on) so no firmware issues and would boot to recoveryOS. The recoveryOS partition was 10.14 Mojave the version that shipped with this MacBook Air when it was new. In 2023, this version is quite old and well out of support, but would be fine just to get the device with a working macOS operating system on the system disk, but this was going to be a bigger challenge than I first thought.
“The recovery server could not be contacted”
The “Reinstalling macOS” option from macOS Utilities would start the installer and allow you to click install, but then hang for a good 20–30 seconds before then erroring out with:
The recovery server could not be contacted.
There’s a lot of information about this error and many resources claiming to provide solutions to it. Let me tell you, none of them worked.
Suggestions I tried included:
- Checking the network connection was working — Opened Safari within recoveryOS to confirm internet connectivity and all OK.
- Trying another network connection — Tested on 3 different networks not related to each other all using fast fibre connections.
- Using Ethernet instead of WiFi — I admittely didn’t do this but ignored it because it shouldn’t matter and the only reason why WiFi wouldn’t work is if it was unstable/slow which would be the scenarios above, and I knew the connections I tested were fine.
- Checking the date/time is correct — Confirmed in terminal with a date command and also used
sntp -sS time.apple.comto ensure synced to a network time server. - Tried manually setting the date/time to in the past — This apparently was suggested to bypass any SSL certificate issues due to the older version of macOS. It didn’t work.
- Remove the device from iCloud before proceeding — I had the owner remove it from their Apple ID and tried again with the same result.
Yet after all this, still the same error. I did not find any other solution or rationale for why this error was present and still don’t fully understand the condition that triggers it even after resolving it. While macOS 10.14 Mojave has been out of support for a while, I can’t imagine Apple would go and delete the recoveryOS server file locations in the event of older Macs needing to be fixed, would they?
Internet recovery “A Software Update is Required to Use This Startup Disk.”
Because recoveryOS was in a bit of a sorry state, there is also the Internet Recovery option and being on 10G fibre link at work, this wouldn’t be too bad, so using the key combination of Option-Command-R, I started the internet recovery process to try and install the latest macOS version instead. This also worked and gets into the internet recovery but then the following message:
A Software Update is Required to Use This Startup Disk.
There is an option to update, so I let it happen and then we get the black screen with the Apple logo and progress bar for a few seconds before it errors out with a generic error. Oh dear, the second recovery option has now failed.
Discovering external disk booting is locked out by the firmware
At this point, it would now be the time to prepare a bootable USB of macOS to use that to install from. The problem I discovered was the firmware setting for booting an external startup disks i.e. USB was disabled, this is related to the extra protections provided by the T2 chip. This explained why when attempting to boot to a perfectly working macOS USB installer would simply be ignored and go for internet recovery. To further compound the situation, guess what is needed on a device with a T2 chip to change this setting?
- A functioning macOS operating system on the system disk
- An administrator account.
That’s a problem. Trying to change any startup settings within the Startup security utility within recoveryOS without any operating system will yield:
No administrator was found.
This technically isn’t an error because it is very much true. This is due to the requirement of a SecureToken being needed to elevate the session to allow such settings to be changed. We however cannot provide such a token when there’s no operating system. We have now got into a situation where this setting is now permanantly locked out without an operating system and neither the recoveryOS installed on the machine or internet recovery are able to reinstall macOS. We are now really in a horrible loop where this device is now stuck in what initially looks like a working but increasingly horrendous state.
The most important thing for anyone who happens to come across this, for any iMac, MacBook Air, MacBook Pro device that has the T2 chip, make sure to make any firmware setting changes required before you go and wipe the system disk. Seriously. For me however, it’s too late. I didn’t put the device into this state, so I don’t have to feel bad, but I now have to deal with the problem.
Running a macOS installer off a USB from inside recoveryOS (failed)
We are now really starting to go down some more exotic/creative solutions given our firmware lockout scenario. It is possible to run a macOS installer from a USB inside recovery OS, you can start the installer from a Terminal window, but you’ll quickly hit a problem. When you select the system disk as the target, you’ll be asked for… an administrator account, which of course with no operating system, I do not not have, so that quickly ends that attempt of bypassing. Nice try though. The T2 chip probably laughing at me thinking its protection could be defeated so easily.
Restore a working macOS environment onto the system disk using Disk Utility (failed)
Knowing that we cannot install anything directly, what about using another Mac to install 10.14 Mojave onto an external disk i.e a portable SSD and then restore this using Disk Utility within recoveryOS onto our troubled MacBook Air? It was worth a shot, with a spare Intel Mac this was performed, 10.14 Mojave was installed to external disk and once getting to the OOBE setup for macOS, powered off and then that external disk plugged into the MacBook Air running within recoveryOS. Using Disk Utility, the external disk was used as restore source for the system disk. Everything looked to be going well, until right at the end when it kept erroring out on a final stage related to APFS with an input/output error, never a good sign.
I’ve since read that APFS can be tricky with restores. Perhaps this may have worked if it was using the older MacOS Extended Journaled format. The problem is that despite formatting the disk as Extended Journaled, the installer at some point erased and repartitioned the disk as APFS, so this solution was also not successful. This is however not surprising given APFS is the newer format and common these days, only even older versions of macOS would let you use the Extended Journaled format. I also read some information around using the dd command instead to perform the copy, but it seemed like further work would be needed around modifying volume IDs and other disk areas which I didn’t go further with.
Reflashing bridgeOS (the working solution)
Spoiler alert, this was the only solution to get things working again, but I’ll explain in more detail. Because this Intel MacBook Air has a T2 chip it also has Download Firmware Update (DFU) mode. This is a specific mode which a device can receive a specific payload, in this case a firmware payload which is known as bridgeOS.
With DFU mode you can either perform a revive or restore. A revive is often recommended first, then if unsuccessful a restore. From Apple’s own documentation this clarifies the two processes:
A revive updates the firmware on the Apple T2 Security Chip. A revive is designed to not make any changes to the startup volume, the user’s data volume, or any other volumes. User data may be retained if recoverable.
The somewhat drastic but final solution would be do to a restore of the firmware. This however has a very different consequence.
A restore updates the firmware and erases recoveryOS and macOS on your internal storage. When this process is complete, any data on any internal volumes is unrecoverable.
Essentially, revive will attempt to bring back the firmware to allow the system to power on and potentially boot an existing volume or allow for recovery of data that might exist on the disk. A restore will nuke the internal storage completely (including recoveryOS) and any data will be gone. At this point, as this disk has already been deleted, that’s not really a problem.
To perform either of these, you require another Mac as the host with the Apple Configurator tool along with a compatible USB-C cable to link between the two devices. Using the original Apple provided cable is usually a good idea, but non Apple USB-C cables can also work, providing they provide both power and data. There is an alternative open source tool that also supports performing these actions outside of needing a Mac host, but you’d need to have some experience with compiling source code, command line and not the official supported method.
For version 2 of the official Apple Configurator software, this also requires at least macOS 12.4 or above. This is where things can get tricky as having another Mac spare isn’t necessarily on hand to everyone and then the additional requirements of minimum environment versions too. I also read that the host Mac device also needs to be running the same macOS version as the target, but I found this misleading and not referenced anywhere within the official documentation, as this certainly didn’t match when I did this, and it still worked.
The logic as to why I am now about to basically reflash bridgeOS to a perfectly working Intel MacBook Air is because internet recovery doesn’t work, the recoveryOS partition is also not working and while this device has no firmware issues in terms of powering on, I am locked out of being able to change any firmware settings, the device is not really able to get macOS installed to the system disk in any conventional way, so I guess that qualifies?! That’s what I’m telling myself anyway.
There’s a few guides out there on DFU mode, although Apple’s own covers most aspects the table of contents has instructions for both Intel and Apple Silicon, but here’s a video just to help illustrate the process for this device, being an Intel MacBook Air.
When first attempting a restore for this MacBook Air, the process started but then presented the message after step 2 (downloading the payload):
A software update is required for this device
The options were Stop, Restore Anyway and Quit and Update.
I chose to Quit and Update. I mean I guess having updates beforehand is good right? At this point it’s somewhat of a unknown about what exact payloads are being downloaded here, blind faith in Apple’s DFU process. Starting the process again this time proceeded through flashing the firmware. The MacBook Air presented a black screen with the Apple logo at the top and then a progress bar down the bottom, near full/completed. This however didn’t seem to ever move for several minutes and the Apple Configurator window just showing a dialogue box of Step 4 installing system with no progress bar moving either. Now I’m quietly trying to not to panic. The process can take a few minutes, so I let it sit. The last thing you do is interrupt a firmware flash!
After a few minutes the MacBook Air seemed to power itself off and then the Apple Configurator window changed to a padlock and warning icon underneath “Apple Controller”, no error, success or complete message. I mean firmware flashing isn’t exactly glamorous or user friendly but whatever, let’s try and boot the MacBook Air and hope it’s now not bricked! If the firmware restore was successful it will have literally erased everything, therefore we need to trigger Internet Recovery as soon as it boots.
Booting up and triggering Internet Recovery took a bit of time, several seconds of blank screen (and mild panic), but eventually an Apple logo appeared and we at least have some sign of life and that the firmware is no worse off. Great! Internet Recovery started and took longer which was potentially a good sign as it needs to essentially rebuild recoveryOS now too. After about 10–15 minutes back into MacOS Utilities. As this laptop shipped with Mojave, it’s now recreated a new recoveryOS environment with that same version. Checking Disk Utility the firmware restore has indeed nuked the internal storage entirely, the system disk was not only blank but uninitialized, now to create a new APFS partition to provide a system disk target for installing macOS.
Selecting “Reinstall macOS” and clicking Install led to the same behaviour of the installer hanging on that screen… Oh no, please…. but this time, the next screen for agreeing to the licence agreement came up. YES. I’ll agree to anything at this point just install macOS! Here we are, finally installing on this troubled MacBook Air.
After that, it was just like a normal macOS install, initial installer phase, reboot, more progress bar, time remaining, reboot again etc. Eventually, we are at the OOBE setup as if it was brand new and finally I can deem my efforts a success. One MacBook Air that now has an operating system ready for setup. While 10.14 Mojave is old, it is probably best just to get the original owner to create a user account and let the usual software update process inside macOS do its thing. I didn’t actually check if the firmware restore cleared any previously set settings and allowed external disk booting, but we technically don’t need it now anyway, however once an account is created, this can be used to unlock any firmware settings we previously couldn’t due to being locked out.
Summary of what’s happened
- recoveryOS on the system disk was unable to reinstall macOS due to the “The recovery server could not be contacted” error. I can only assume that the firmware settings/environment provided by the T2 chip was the primary issue for errors related to reinstalling macOS.
- Internet Recovery could not update or modify the existing recoveryOS data to install a newer version of macOS.
- The MacBook Air had been wiped before changing the external disk booting setting in the Startup utility. This had put the device in a bit of precarious state and cut off a final rescue option with USB booting.
- Only a DFU firmware restore to fully wipe the disk and recoveryOS to then completely reinstall has worked and cleared the error that was blocking the previous attempts.
It is also worth noting that Mac’s with a T2 chip and with more recent macOS versions like Monetary and Ventura installed, have an erase feature built in. Using that is far safer and easier compared to using recoveryOS and nuking the system partition using Disk Utility, but this can only be done for newer models, but the MacBook Air Late 2018 is one of them. What’s further interesting is using DFU mode is being made easier by Apple themselves building DFU functions straight into Finder.
I hope this information might help someone else in my situation. While I’m not an Apple/Mac expert, this is most challenging MacBook I’ve worked with to date given all of the roadblocks just to get a working OS on it when it should in theory be easy and that’s coming from someone who’s previously done a firmware reflash using a SOIC clip and external device to erase a firmware password (for legitimate reasons!) on an older MacBook Pro.
