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.
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.
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.
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.
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.
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.
@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.
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.
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
@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)
the way i have used to fix that issues is from this site
"I was just given the steps below to follow by an Apple chat tech that oddly worked.
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.
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
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.
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.
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.
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
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.