Big Sur 11.5.1 will not install on ARM macs

[dugnl]

Intel Macs, 11.5.1 works.  Macs not in JAMF including ARM 11.5.1 installs.

DEP ARM macs, configured via JAMF prestage will not install 11.5.1. 

Users are signed in with an admin created via system preferences and one created via the prestage setup.

After clicking restart now, get the prompt, "Software Update is trying to authenticate user" Enter password for the user "username" to allow this.  Enter that users password.   Box goes away and another box pops up saying  "Some updates could not be installed."

There was an earlier posts about securetokens, however these accounts have secure tokens...it is enabled.  It's not the wrong password because entering the wrong password shakes the password box.

Multiple ARM based macs in our environment in different locations and different networks.

Computers both on domain and off domain.

I have opened a ticket with JAMF as I believe this to be a JAMF issue since testing ARM macs not in JAMF works fine.

There are no restrictions for ARM based macs to not receive the updates.  We do have a 7 day restriction for updates but do not apply that restriction to ARM at this time (and I've certainly excluded my machine). If it was a restriction, would not have even got to the download screen.

I have no idea why this works on the intel macs with Big Sur but not on these ARM macs.

[mmcallister]

Hi @dugnl 

Tried to replicate this but was not able to.  My M1 MacBook Air is enrolled via PreStage and installed 11.5.1 without a problem.  Hopefully Jamf support can help you out with the issue.

[dugnl]

A week later and with an Apple Ticket and a JAMF ticket, we've come to discover that none of our fleet of over 200 M1 macs will go to 11.5.1.   The majority are out of the box 11.2 and through system preferences will not update to 11.5.1.     "some updates could not be installed"

I thought it was only affecting a few 11.5.0 to 11.5.1 macs but no, it's pretty much our entire fleet.  We have 200 cause a school bought a bunch for their students.    So, this is having a significant impact on us.

Will be doing further and stronger escalation tomorrow.

[dugnl]

removing the JAMF framework restores our ability to install 11.5.1 via system preferences/software updates.  This shows it's 100 percent JAMF preventing the installation.

We have no deferral policies nor do we have any restrictions on installing this software.   We have two sites and it affects both sites.  We have no configuration profiles affecting both.

Another workaround is bringing the full installer down and running it from applications....not desired.

[dugnl]

This is the response from JAMF.   I'm not happy with this and the money we pay to have stuff working.  FYI for others.

Thank you for testing this, Doug!

We’ve discussed this issue with our team, and found that a product issue regarding this behavior was just recently created..

The product issue number is PI-010001 with a brief description below:
Third Party: ‘Recently activated or DFU restored computers with Apple silicon may not be able to install macOS updates. Error message may state "Some updates could not be installed."
  
At this time (not ideal), the only workaround we have available for this, is to remove the MDM profile, update the OS & reenroll the machine into Jamf, which we just recently did.

Apple is aware of this issue and is actively investigating. Since you are already in touch with Apple, they may request debug logs to help troubleshoot this further.

[cvill]

We are having the same issue.
We cant find the PI-010001 

[dugnl]

JAMF response: The product issue number is PI-010001 with a brief description below:
Third Party: ‘Recently activated or DFU restored computers with Apple silicon may not be able to install macOS updates. Error message may state "Some updates could not be installed."

Apple's Response (missing context of my response to Apple but lets just say I wasn't pleased)

From: Apple Support 
Date: Monday, August 9, 2021 at 3:17 PM

Subject: Re:ARM Macs Can't upgrade to 11.5.1. Some updates could not be installed

Hi Neal,

Thanks for the updated information you shared about JAMF PI-010001. I definitely feel and share in your pain over situations like this most recent dust-up initiated by our 11.5.1 update. The product revision cycle can at times feel way ahead of the documentation revision cycle, leaving those in our roles (yours and mine, respectively) often playing catch-up just hoping to learn a workflow or how a feature should work.   

In this case, what I'd found in the logs showed that a credential was saved, then when it was time to use it, it wasn't the proper token anymore, perhaps due to how a user context was evolving during the procession of the installer through it's various condition checks and module installations.  This tended to implicate the MDM process.  Thanks for your note of validation and I'm glad to hear of your successes.  Please let me know if you have any questions.

Regards,

Steve Baughman

AppleCare Enterprise Support

[dugnl]

I've emailed jamf about the missing PI listed on https://account.jamf.com/products/jamf-pro/known-issues

[dugnl]

In reference to the missing PI, here is JAMFs response.

From: Customer Success - success@jamf.com <success@jamf.com>
Date: Wednesday, August 11, 2021 at 12:16 PM
To: Neal, Doug R <DougNeal@creighton.edu>
Subject: Re: ARM macs DEP enrolled in JAMF can't update to Big Sur 11.5.1 [ ref:_00D80cOw4._5000h1mVOA6:ref ]

Hello Doug,

Jordan here with Jamf Customer Success. I’m very sorry to hear about the issues upgrading your Macs. I understand how frustrating this must be. 

The reason you are not seeing PI-010001 listed in the known issues is because this is currently classified as a third party issue, and not a Jamf product issue specifically. We are using PI-010001 for the purpose of tracking internally and providing workarounds to customers who run into the same issue, however, Apple will need to be the ones to fix this overall situation.

As Doeneah mentioned, Apple is aware of this issue and is actively investigating. Hopefully a resolution is provided sooner than later. 

I wish I had better news, but thank you for your patience while this continues to be worked on. Feel free to reach out with any further questions. 

Thanks,

Jordan King
Customer Success Manager
Jamf
success@jamf.com

[dugnl]

I found a third workaround.     go into Recovery, Utilities and Startup Security Utility and change the Security policy from Full to Reduced.  I did not check any other option.

At that point, was able to successfully restart my Mac via system preferences and update to the latest Big Sur on ARM Macs.

It's strangely as if the Mac doesn't think the updates were legit.   I was not able to update to 11.5.1 nor 11.5.2 until I made this change.

I'm going to introduce this into our ARM Mac workflow (which does mean we manually hand out Macs preconfigured)

https://support.apple.com/guide/mac-help/macos-recovery-a-mac-apple-silicon-mchl82829c17/11.0/mac/11...

[dugnl]

https://support.apple.com/en-us/HT212745

Short version is Apple had an issue between certain dates which broke stuff big time on ARM.

We fell into this because we deployed over 200 ARM based Macs during this time.

[erik_crouch]

Thanks for sharing this, was pulling my hair out... I knew our workflows were M1 compliant because I have a test subject that I've wiped and re-installed several times, argh! 

[mapurcel]

strange i have an M1 experiencing this problem which was deployed last December when they were first released...i used your recovery workaround and that did the trick..