hoakley June 18, 2021 Macs, Technology

Is there still something amiss in the M1 firmware?

Wonderful though the M1 Mac’s new Recovery system is, there’s a problem which has been plaguing a few users since the first of the new models shipped late last year. When in Recovery (or elsewhere) you erase your Mac’s internal storage to reinstall macOS, just when you start that reinstallation, up pops up the error message: “An error occurred while preparing the update. Failed to personalize the software update. Please try again.” I explained this, and linked to Apple’s support page, in this article on 26 November, almost seven months ago, yet users still encounter this in macOS 11.4 and in current beta-releases.

Perhaps inevitably, Apple neither explains what is going wrong, nor does it tell us how we can avoid this from happening, other than by avoiding erasing internal storage in this way. Neither does it make clear that the erasure doesn’t actually erase the whole disk, only its macOS container. This still leaves two other containers, with the ‘firmware’ and recoveryOS on them, which can only be completely erased when you boot your M1 in DFU mode and restore from an IPSW image, something Apple details in this article from the Configurator Help book.

The evidence from Apple’s advised solutions only strengthens the case that this is a continuing bug in the firmware or recoveryOS, or possibly in the Big Sur installer. It’s a serious bug too: although it occurs infrequently, solutions are quite technically challenging and the only way to recover that Mac.

Apple’s primary solution is to revive or restore the whole internal SSD with the Mac in DFU mode, which requires a second Mac running at least Catalina 10.15.6 and a suitable cable. In practice, of course, reviving the firmware is insufficient, as you also need to install macOS to go any further. At least a DFU mode restore is quite quick and painless, however daunting it might seem at first.

If you can’t do that, solutions proposed rely on a hidden Erase Mac command initiated through Terminal in Recovery, followed by reinstalling Big Sur. As these methods aren’t described elsewhere, I’ll explain them here.

Erase Mac in Recovery

Normally, erasing your Mac in Recovery only wipes the macOS container, and doesn’t clear the other two containers. It appears that there’s one manoeuvre you can use in Recovery to go further than that. Open Terminal there, and type in the command
resetpassword
following which you should click in the Reset Password window to bring it to the front. Then open the Recovery Assistant menu, and select the Erase Mac command. That opens another window titled Erase Mac, in which you should confirm by clicking Erase Mac again. Your Mac will restart automatically, and will then prompt you to select a language. It will inform you that macOS needs to be reinstalled, which you should continue with. Your Mac then activates by connecting to Apple over the Internet.

Extraordinarly, Apple recommends that in this case, if you have seen the warning about failing to personalise, you should repeat these steps a second time, starting with the resetpassword command.

Even then, you’re still not done, as you have yet to reinstall macOS. To do that, Apple recommends one of three actions:

Reinstall Big Sur using the main Recovery window.
Restart from a Big Sur bootable installer, if you happen to have one available.
Reinstall using Terminal in Recovery, as explained below.

Reinstall macOS in Terminal

The official procedure for reinstalling using Terminal in Recovery isn’t simple either. You’ll need to enter the following commands
cd '/Volumes/Untitled' mkdir -p private/tmp cp -R '/Install macOS Big Sur.app' private/tmp cd 'private/tmp/Install macOS Big Sur.app' mkdir Contents/SharedSupport curl -L -o Contents/SharedSupport/SharedSupport.dmg http://swcdn.apple.com/content/downloads/55/59/071-00696-A_4T69TQR1VO/9psvjmwyjlucyg708cqjeaiylrvb0xph94/InstallAssistant.pkg
These create a temporary folder within a macOS installer to contain Install Assistant, and to download that. Once that has completed, type into Terminal the command
./Contents/MacOS/InstallAssistant_springboard
to start the process of reinstallation.

Choose macOS version

The other important issue which Apple doesn’t mention is which version of macOS you should install after all this. It appears most likely that this problem occurs when you have had a beta-test version of macOS installed, and you want to revert to a release version instead. If you restore in DFU mode, then you can select which IPSW image file to install, download that before putting your Mac into DFU mode, and use that IPSW for the restore. You can also pick which version of Big Sur to use on a bootable installer. However, in the other two methods you get the version that Apple provides.

Although this problem appears relatively infrequent, it’s a serious bug which seems to have affected users for seven months. It needs to be fixed, please.

I’m very grateful to ‘slice’, who took the trouble to explain to me what happened to their M1 MacBook Air just a few days ago.

23Comments

Add yours

1

slice on June 18, 2021 at 6:52 am

Extremely honored and grateful to contribute to this wonderful blog!

My encounter was extraordinary considering that the installation succeeded, yet the system failed to grant my user a secure token after restoring from a Time Machine backup. Hopefully this issue will be resolved in future versions, as it is incredibly unintuitive when seemingly random components of the system (such as FileVault) start to fail.

P.S. macOS Monterey DB1’s recoveryOS doesn’t have a /Volumes/Untitled. It appears to have been renamed to “/Volumes/Image Volume”. For posterity, the other volumes are “Macintosh HD” and “macOS Base System”.

LikeLiked by 1 person
2

slice on June 18, 2021 at 6:56 am

Whoops, look like my comment posted twice. Could the duplicate be removed, please?

LikeLiked by 1 person
- 3
  
  hoakley on June 18, 2021 at 7:12 am
  
  No problems – done.
  Without your report, I’d still have believed that Apple had resolved this problem, so we’re all very grateful to you. As far as I can tell, it’s essentially identical to the problem which hit some when trying to update from 11.0 to 11.0.1 all that time ago.
  Howard.
  
  LikeLike
4

Nick on June 18, 2021 at 8:06 am

Excellent reporting, as always! It’s a great shame that Apple will not engage directly with issues like these, acknowledge there is a problem (or maybe say why there isn’t a problem in some cases), and advise what they will do to resolve them. That would increase my confidence in Apple whereas the existence of problems like this without any acknowledgement reduces it.

It is surely better to know that there was an issue which has now been resolved, or even is going to be resolved, rather than find out there is an issue with a vacuum of information from Apple about it.

It feels like we are all continually on slightly shifting sands, and Apple relies on the ignorance of its customers and the relative unlikeliness of issues like this occurring rather than facing up to them and coming clean. What are they scared of?

We all, I believe, recognise the underlying excellence of the products, but in my view there is a shortfall in true professionalism and polish on their part which is immensely frustrating. And I am not suggesting that Microsoft is any better in terms of the robustness of their product, but they do at least acknowledge and publicly address issues, which is probably one of the reasons that the IT community continues to consider Windows as a more “professional” product than macOS.

LikeLiked by 1 person
- 5
  
  hoakley on June 18, 2021 at 1:00 pm
  
  Thank you.
  Howard.
  
  LikeLike
6

Pico on June 19, 2021 at 5:43 pm

You might be interested in this. It was in regards to a discussion about internet being required during an macOS install/update for the T2 iBridge firmware (so the Secure Boot stuff is talking about T2 Macs), but I believe “personalization” of macOS on M1 is essentially the same. Basically, internet is required for personalization during a T2 or Apple Silicon install/update even if all install/update resources are available locally.

Posted by https://twitter.com/mikeymikey (an Apple employee) on MacAdmins Slack:

“Personalization is a signed record from Apple approving the installation that matches the provided details, including unique identifiers for the device you’re doing the install for.
Both bridgeOS and macOS need personalization records. Turning off or modifying Secure Boot settings changes what’s required there for macOS but not bridgeOS.
asr restore installs macOS and can read over the TDM connection the necessary details to get the personalization record for macOS for the attached hardware and include that in the asr restore – but doesn’t address bridgeOS updates/personalization at all.
macOS has a “minimum bridgeOS required for boot” encoded into it. asr restore something to a Mac that doesn’t have a new enough bridgeOS = that Mac at power on will not boot macOS until it bridgeOS has been updated”

And “I wrote about it in one of the last serious technical blog posts I did before joining Apple: http://michaellynn.github.io/2018/07/27/booting-secure/“

LikeLiked by 1 person
- 7
  
  Pico on June 19, 2021 at 5:52 pm
  
  (The ASR stuff in the first quote I posted in the previous comment is about restoring a T2 Mac using ASR over Target Disk Mode.)
  
  Also, from earlier in the discussion:
  
  “Turning Secure Boot off does not negate the need for network access if the update requires updating bridgeOS of the T2 itself (most macOS updates include associated minimum bridgeOS version updates)
  
  While macOS may boot insecure, bridgeOS which brings up macOS never does.
  The only way to “offline” update bridgeOS on the T2 is with Apple Configurator 2 and even in that scenario, the Mac running AC2 will itself need network access during it”
  
  And:
  
  “To upgrade bridgeOS, you need a signed individualized personalization ticket from Apple’s online service – no way around it”
  
  The mention in these quotes about “The only way to “offline” update bridgeOS on the T2 is with Apple Configurator 2 and even in that scenario, the Mac running AC2 will itself need network access during it” is interesting since I assume that also applied to Apple Silicon Macs. The Mac performing a DFU restore of an Apple Silicon still needs to have internet during the process to do the personalization for the connected computer.
  
  LikeLiked by 1 person
  - 8
    
    hoakley on June 19, 2021 at 8:09 pm
    
    Thank you, Pico.
    Yes, you do need Internet access for Configurator. Listed in the requirements in its Help book is:
    “Internet access
    You may need to configure your web proxy or firewall ports to allow all network traffic from Apple devices to Apple’s network 17.0.0.0/8. For more information on the ports used by Apple products, see the Apple Support article Use Apple products on enterprise networks. For more information on whether your network uses a web proxy or firewall, consult your router manual or your internet provider.”
    Howard.
    
    LikeLike
- 9
  
  hoakley on June 19, 2021 at 7:58 pm
  
  Thank you.
  This problem has arisen in M1 Macs which should (unless the firmware has a bug) have reliable Internet connections for ‘personalisation’ to take place. It’s not a user error. This requirement for an Internet connection is well documented, and as far as I recall explained in the Platform Security Guide too.
  When they were reported in the first M1 Macs, they occurred when updating them to 11.0.1 went wrong, and the macOS container was erased to start afresh. Many users were successful, but some hit this error, and Apple’s solution ran much the same at the time. This most recent case occurred in an M1 Mac which had 12 beta installed (so had its firmware and Recovery) and then had its macOS container erased in order to downgrade to 11.4.
  @mikeymikey is also well worth following on Twitter, although most of his tweets about Macs centre on sysadmin issues. He’s one of the most helpful and communicative of Apple’s staff there, and a really good guy to boot. He used to be a superb researcher and blogger too.
  Howard.
  
  LikeLike
10

Bryan Christianson on August 31, 2021 at 6:33 am

And the problem persists when trying to update Montery beta 5 to Monterey beta 6 on my M1 MacMini. The odd thing is that upgrade to beta 5 earlier in the month had worked perfectly. This time I was hit with the ‘personalization’ message with the only option being to wipe the internal drive.

What should have been 30 minute task turned into 3 1/2 hours. I had to reinstall with Configurator 2 to get my 11.5.2 Volume(s) going, recover the user data, then build a new set of volumes (in the same container as Big Sur) for Monterey followed by another clean install with data recovery, then 2 Monterey updates to get me to beta 6.

I sure hope this is not going to be a persistent issue.

LikeLiked by 1 person
- 11
  
  hoakley on August 31, 2021 at 7:36 am
  
  Thank you.
  I got up this morning to complete my update, and once beta 6 started up it informed me that there had been a panic during the update. So off goes the sysdiagnose. The update seems fine now, though.
  Howard.
  
  LikeLike
12

sebus on October 6, 2021 at 4:56 pm

BS 11.6
Erased disk from resetpassword in Recover boot
Rebooted again, it activated itself (why?, still do not get it)
Booted to USB Installer, installed to external USB-C SSD
Booted to this USB External drive and now in Terminal managed to erase Internal drive Recovery partition disk0s3

Tried to reboot to Options, but only for circled !
Rebooted, booted to USB fine

Tried to run installer, failed with Personalization error, twice

Run in Terminal startosinstall

Run to 103.6%, failed

Rebooted, pulled out USB, it booted to something. Will see what because I left work

LikeLiked by 1 person
- 13
  
  hoakley on October 6, 2021 at 9:26 pm
  
  I’m sorry to hear of your problems, but can’t for the life of me understand what you’re trying to do. Perhaps if you were to explain that I could suggest a less troublesome way of getting there.
  Howard.
  
  LikeLike
14

sebus on October 9, 2021 at 7:07 pm

Trying to destroy it, and find an easy way to rebuild it, preferable without second Mac connected (which IMO us a total insanity)

After all, it never came back, still gave the circled ! with link to Apple recovery site

Madness

LikeLiked by 1 person
- 15
  
  hoakley on October 9, 2021 at 7:18 pm
  
  Ah. You’re one of several people I’ve known try this.
  I’m afraid it’s doomed to failure, because M1 Macs always boot from the Pre-Boot container on the internal SSD. Among other things, it contains all the stored data for the SEP. Your M1 can’t wipe that and survive, unless booted in DFU mode, which does run independently of the internal SSD. And that’s why you can only restore an IPSW image from a second Mac, in DFU mode. It’s neither insane nor accidental – it’s entirely intentional, and part of the Secure Boot design.
  Howard.
  
  LikeLike
16

sebus on October 11, 2021 at 8:08 pm

Thanks, it is insane design (to need another physical device) that could only be made by Apple

LikeLiked by 1 person
- 17
  
  hoakley on October 11, 2021 at 8:23 pm
  
  No, I’m afraid that I beg to differ completely. It’s excellent design from a security point of view. That’s part of Secure Boot, and why Apple Silicon Macs are so much better than Intel Macs.
  It is truly exceptional for any regular user to need to put their Mac into DFU mode for a restore.
  If you were designing an M1 Mac, where would the SEP store its data, if not on the internal SSD? If it does store them there, then if they are erased, how else can you recover the system except using a second Mac?
  Howard.
  
  LikeLike
  - 18
    
    sebus on October 12, 2021 at 7:02 am
    
    Not to be able to just erase internal HD (any way I like, and not the way Apple tells me to) and fully reinstall OS on it, that is mad!
    Could be mad by design, but it is still mad.
    Everybody can have they opinion. But let’s not talk about security, if one can erase all the data on M1 by simply going to options with no password anywhere on the way…
    
    LikeLiked by 1 person
  - 19
    
    sebus on October 12, 2021 at 3:28 pm
    
    Thanks, that is definitely the case, I just hate M1, final
    
    LikeLiked by 1 person
    - 20
      
      hoakley on October 12, 2021 at 5:07 pm
      
      I’m sad for you. However, I’m delighted to say that Apple isn’t going to change its mind on this security design for a good while, I suspect.
      In around 15 months of hammering Apple Silicon Macs, from the early DTK to the two M1 Macs I have at present, I’ve only needed to put one into DFU mode once, and that wasn’t to perform a full restore, just a refresh, and even that probably wasn’t necessary.
      Howard.
      
      LikeLike
    - 21
      
      sebus on October 12, 2021 at 7:35 pm
      
      But I am not a Mac user (and surely not a normal user even when using it)
      I would never spend money on Apple hardware, just hate administering the lot
      
      LikeLiked by 1 person
22

sebus on October 11, 2021 at 8:10 pm

Well, it does not always boot from Internal drive, because it boots fine from EXTERNAL Seagate Fast SSD (with internal drive buggered as it is)

LikeLiked by 1 person
- 23
  
  hoakley on October 11, 2021 at 8:26 pm
  
  I’m sorry, that’s simply not correct. If you damage the Pre-boot container on your internal SSD, that M1 Mac becomes unbootable. Every single boot starts from its internal SSD – if you don’t believe me, try reading Apple’s Platform Security Guide which explains the process in detail. You can also cross-check with the Asahi Linux Project, which has been working out how to boot Linux from there.
  Wipe the internal SSD of any M1 Mac and the only way you can get it to boot again is to put it into DFU mode and perform a Restore using an IPSW image from another Mac running Configurator 2.
  Howard.
  
  LikeLike