Big Sur M1 Mac + Filevailt 2 - Admin user = Big problems

hkabik
Valued Contributor

After configuring our first M1 machine we ended up with the attached error. "Recovery is trying to change system setting. No Administrator was found."

This happened after a reboot in which some system and kernel extensions were installed by policy and approved via config profile. Our machines have local admin accounts, but only the user account is FV2 capable and they are not an admin. That appears to be the crux of the issue.

Sadly I can't troubleshoot further because once you get this error, the only option is to erase/restore. And I was getting this error: https://support.apple.com/en-us/HT211983

and while I was able to restore it via the configurator approach yesterday, I cannot today because the boot key command will no longer get the machine into revive mode and recognized by configurator. Apple support is stumped and is just sending me a new machine... they believe this one is just bricked. I restored it probably 4-5 times yesterday. today it's a paperweight that can't install an os.

So... has anyone else seen this "No Admin" error? Any solutions I should attempt once I get my replacement M! machine? Need to look into reworking our workflow so our admin account is also a FV2 user?

Mostly I want to direct attention to both this "no admin" error's existence and just how absurdly easy it is to brick these M1s apparently. Tread carefully, but also be aware Apple is swapping these out pretty readily if you do.

522663e47afe4338b1f264022cb75929

43 REPLIES 43

vailster-cc
New Contributor

+1 for also getting this error in the same situation!

hkabik
Valued Contributor

So the “No Admins” issue on M1 Macs. It appears it is in direct relation to having a config profile approving kernel extensions on a machine where the only FV2 user is a non admin. If I do not include an config profile to approve the KEXTs then all is well, but if I add the config profile that whitelists them then on the next reboot I am kicked into recovery mode and get the error. no way out but revive/restore. If there IS an admin FV2 user they can then authenticate the change in recovery mode. but per https://support.apple.com/en-gb/HT211860#silicon that should not be the case. As my equipment is configured via automated device enrollment then the config profile should automatically approve the KEXTs without manual intervention.

Phantom5
Contributor II

I would stay away from kexts in Big Sur and M1 Macs. We are experiencing a lot of kernel panics with sec agents that still use kernel extensions in Big Sur to the point that we even have to reinstall macOS. I imagine Rosetta 2 is not going to provide the compatibility that some kernel extensions need.

hkabik
Valued Contributor

Indeed, I've simply disabled all of those profiles and the problem has ceased to be. But this still goes against the data that apple has put forward in https://support.apple.com/en-gb/HT211860#silicon, so I want to let people know if I can in advance.

Wakko
Contributor

So I just ran into this issue. I've been using my machine for about a week and 1/2. No errors no issues what so ever. It' funny that that we are getting this error at the "same time". Now to be clear I have reboot my machine several times before this has happen. So what did Apple push that might've cause this. Everything was working fine, same setup similar to yours. This is no bueno at all. If I find any information that might help us out on this issue I will past it along.

Update:
AppleCare support was , well we all know how I'm going to end that sentence. Needless to say this link helped me bring back my machine. For me step 5 worked, sure it took longer but it was a clean nuke & pave. Hopefully this will help out other admins that run into this issue.

dywane
New Contributor II

HI! I have seen this error before. I my case, the user booted to the optoin screen, navigaed to Disc Utility and erased the drive, and then tried re installing the OS from the Utilites menue. It was during the install process that mac produced the error "No Administrator was found."

hkabik
Valued Contributor

Please anyone who gets this, reach out to Apple enterprise support. My issue was escalated to engineering yesterday and they specifically said they are on the lookout for more instances of this error.

kevin_v
Contributor

What version of Jamf Pro are you running?

hkabik
Valued Contributor

10.26

daniel_blohm
New Contributor

Just a thought without testing (still waiting for the first M1).
I just stumbled upon this: 25879097236e46fcbbf93a686ef649d6

In my understanding, if "Allow standard users" is checked the machine would not need an admin to approve the extension. Maybe you can circumvent the problem this way?

Regards
Daniel

matthias_bretz
New Contributor III

Did you try to recover the M1 mac in DFU-Mode? Had to do this last week as any other attempt did not bring him back to life.

Another tidbit: my Jamf server just failed to install my profile with approved kernel extensions. So I made a smart group for all macOS 11.X (and newer) computers and excluded this in scope of my kernel extension profile to get rid of the failed installs in Jamf.

jgaitherccu
New Contributor III

Just got off a chat with Apple Support and this worked for me: https://support.apple.com/en-us/HT211983

Specifically Steps 1-9 under Prepare Your Mac. For some reason wiping it from resetpassword in Terminal made the difference and we were able to reinstall the OS after that.

hkabik
Valued Contributor

The "Allow standard users" option for legacy KEXTS doesn't change the outcome. You still are booted to recovery and get the "no admin" message.

Only option to get back into the os is a wipe restore at that point.

Wakko
Contributor

@hkabik I just got a call back from Apple. Engineering is call a few questions that I"m just gonna copy and paste from JAMF. This is something that they "seem to be aware of". I basically also told then if they need more info that they should basically give us machines to test. Since this is finished and paid for product, why should I spend time beta testing it for them. This is starting to not feel like a finish product and if so then it should be full price. Time = $, $= time in IT simple equation.

lassekivikas
New Contributor II

In my case, I had this exact same problem. I got through first boot that was automatic after jamf enrollment, but the next one got me the same "Recovery is trying to change system setting. No Administrator was found." error. I also had Kexts deployed from Jamf, but removing them didn't do anything.

What I found out, is that the first authenticated account got the SecureToken but we create hidden admin account in prestage enrollment, and that hidden account doesn't get SecureToken before you sign in with it. I checked it with sudo sysadminctl -secureTokenStatus username. After signing in and checking that both accounts have the SecureToken, I got through the boot normally.
For the reference, I am using Jamf Pro 10.26.

kmathern
New Contributor III

I am having the issue as well. I'll follow this thread and hopefully Apple fixes this.

tjosey
New Contributor III

We are running into the same issue here. We recently have received 10 M1 Mac Book Airs and we actually tested out one of them and now its bricked on the same Recovery is trying to change system settings. We do have a hidden admin account automatically created during preinstallation. We will call apple to to escalate and hopefully get a new Mac

maurits-pro
New Contributor II

@hkabik Can you give us more details on which kernel extension you are using?

Here is my line of thought on your issue: There can be two limitations: - macOS 11 has deprecated any kernel extension, but can run if (see below)
- any extension (system and kernel) should be designed for Apple Silicon

What I read in documentation : macOS 11 can support kernel extensions, IF approved by MDM, BUT if the extension is designed some older way ('deprecated KPI' as mentioned in HT211860' ) need 'approval' , which would not surprise me if that approval requires admin rights. (this line: You can use MDM to modify default policies to not show dialogues periodically and to allow the kernel extensions to load. )
So it may be that the exact type of kernel extension is important. ( I am not tech enough to be able to understand the deprecated KPI's)

user-vjnZfpiMRy
New Contributor

Thanks for the update and quick reply. I'll be sure to keep an eye on this thread. Looking for the same issue. Bumped into your thread. Thanks for creating it. Looking forward for solution.

toster1532
New Contributor

the way i have used to fix that issues is from this site
https://mrmacintosh.com/reinstalling-big-sur-on-apple-silicon-macs-with-11-0-20a2411-error/

"I was just given the steps below to follow by an Apple chat tech that oddly worked.

  1. Boot to recovery
  2. Launch Terminal
  3. Run terminal command: resetpassword. (Ignore errors about users if it comes up)
  4. Click on the background to the side of Reset Password window , then choose Recovery Assistant in the menu bar then select Erase Mac.
  5. Click Erase Mac in the window that opens, then click Erase Mac again to confirm. When done, your Mac restarts automatically.
  6. If they are on 11.0.1 it will automatically reboot after the erase is complete. After the reboot select wifi appears, and prompts the customer for activation. When activation completes, they need to choose the option of [Exit to Recovery Utilities] which brings us back to the main recovery screen.
  7. If the activation fails, make sure they are connected to the internet via their Wifi icon. (Some ethernet dongles are not detected in recovery, use Wifi)
  8. Once activation is completed. You will see the normal restore options. Choose reinstall macOS Big Sur."

jgaitherccu
New Contributor III

@toster1532 That was my post, lol. Confused me seeing it reposted here

macmanmk
Contributor

This is insane. It shouldn't be this easy to brick a machine. I don't even have FV2 enabled on my test machine and am getting this error on the first reboot. Not to mention that every time I have wanted to erase the machine and reinstall the OS while testing workflows, I have to restore using DFU through AC2.

alexkaye
New Contributor

Indeed It is insane. I have found on M1 Mac Minis the issue happens regardless of whether I enable FileVault or not. On my M1 MacBook Air the issue does not occur so long as it is on 11.01 and I do not force reboot through Jamf. I have also reported to Apple. On the plus side I am now a master of restoring Macs through DFU mode

Wakko
Contributor

Well if anyone is on Appleseed IT they'll see that a new installer has been cut. Time to start testing agin.

UbiquitousChris
Contributor

I don't know about the rest of you, but this is still happening with 11.1.0. In fact, for me it seems to be even worse.

mconners
Valued Contributor

Is there any way of smart grouping the M1's and excluding them from any previously known approved KEXT's?

hkabik
Valued Contributor

Processor Type - Not Like - Intel

Should work for now.

kmathern
New Contributor III

@Hkabik confirming that does work for anyone out there testing the M1 chips

matthias_bretz
New Contributor III

Or you check especially for ARM-CPUs: Architecture Type is "arm64". Works for me.

cornwella
New Contributor III

We've had this happen with several M1 Macbook Air and Pro devices both with and without Jamf enrollment. From what I can tell there's a firmware build these ship with that's essentially a silent time bomb; anywhere between unboxing them and 2+ weeks of regular use it'll suddenly boot up with the "Recovery is trying to change system settings. No Administrator was found" error. The only way to get them running again at that point is a DFU restore using Configurator.

We haven't seen it reoccur after updating the firmware and letting them install all available OS X updates as the very first step, but sometimes it happens before one even gets a chance to search for and apply any pending updates. Very frustrating.

ThierryD
New Contributor III

+1 same problem in our environment. The only way is to restore the Mac in DFU mode but it doesn't resolve the issue.

timlarsen
Contributor

Unfortunately we're right there with you guys in our environment. And whoever said it is absolutely right that this issue is almost like a "ticking time bomb" since the issue sometimes doesn't occur until the second or subsequent reboots. We've also opened up a case with ACE.

Has anyone found success with excluding your KEXT whitelist profile(s) from M1 Macs prior to enrollment as preventing this issue from occurring, or no?

Thanks! Good luck everyone.

hkabik
Valued Contributor

In my experience, excluding KEXT approval profiles does seem to stop this issue from occurring. But I have heard from others that even when they have done so the issue has still seemed to randomly pop up on a subsection of machines. So my experience, yes that is the bandaid... but it seems there are still unkown circumstances that can trigger it.

ravisgupta
New Contributor III

it appears to do with managed local admin account not having the secure token as it has not logged in (we create standard accounts for users). When I elevated standard user to local admin on system, which in turn allowed it to add secure token on managed local admin account, this issue did not occur for me then, though upon first restart it did as for user's password to unlock the drive to boot the machine.
Looks like will have to prompt user to allow adding secure token for local admin account after elevating user's privileges

ThierryD
New Contributor III

@hkabik Same for me. Excluding KEXT seems to have resolved the issue. I hope it won't trigger for other processes.

tjhall
Contributor III

In my experience the problem with M1's doesn't just rear it's head with kext config profiles.
Using an DEP enrollment; any policy with a package containing a kext will either kick up a dialog prompting for password for "Security Certificate" or fail and potentially cause issues (for example, the Google File Drive Stream package contains a kext and will prompt for password to approve it but will still fail since it's trying to install a kext).
I'm still working my way through our policies and adding exclusions (based on BigSur + ARM architecture) but a good place to start is the inventory of an enrolled M1 Mac and inspect any packages of policies which have failed.

Jason33
Contributor II

I got hit with this today on a MacBook Air

Key1
New Contributor III

Got this today with all the KEXT profiles excluded. Its really intermittent though.

matthias_bretz
New Contributor III

@tjhall: do you mean such a dialog (as attached)?
0a4cef99ee464763a8de90a60ed3a2f6

I noticed this while installing Avast Antivir Business with policy triggered on the command line (jamf policy).
If I just wait for the recurring checkin this won't show up and the install will fail.