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.
Is there any way of smart grouping the M1's and excluding them from any previously known approved KEXT's?
Processor Type - Not Like - Intel
Should work for now.
@Hkabik confirming that does work for anyone out there testing the M1 chips
Or you check especially for ARM-CPUs: Architecture Type is "arm64". Works for me.
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.
+1 same problem in our environment. The only way is to restore the Mac in DFU mode but it doesn't resolve the issue.
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
@hkabik Same for me. Excluding KEXT seems to have resolved the issue. I hope it won't trigger for other processes.
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.
I got hit with this today on a MacBook Air
Got this today with all the KEXT profiles excluded. Its really intermittent though.
@tjhall: do you mean such a dialog (as attached)?
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.
@matthias.bretz
Yes, that's what I'm talking about. If you got any packages that installs kext extensions then you will get these prompts. And since the package contains a kext it will fail.
I have gotten the same error on only 4 of the 100 new M1s that we got. They were all onboarded the same way. Hopefully it doesn't happen to all 100 because we are starting to check them out to our students today.
@Tophernad Are you aware of the minor/patch versions of macOS 11 the failed Macs were on? I'm not seeing this issue on 11.2.3 and it would be interesting to see if Apple have fixed this issue in the more recent versions of macOS.
This is ridiculous that this is still happening. I've got a Securetoken enabled account, which is an administrator (the only administrator account on the machine) and when trying to re-install the OS, get the recovery error message. And I'm trying to do this, following Apple's recommendation, since I have had 2 users report that after upgrading to 11.4, their machines freeze at progress bar after entering their password. Only thing they were able to do is hard shut down the machine, and then they were able to log in.
I was able to overcome this error by disabling Filevault disk encryption and booting to recovery. I then adjust the security to reduced security and rebooted to OS. Then turned back on disk encryption.
Hi,
Sorry I know it's been almost a year since this thread was active but does anyone know if this issue was resolved with any update to Mac OS?
Not as of late, but here is the solution that I am using to work out the error:
User received an M1 from Apple with macOS 12 preloaded. To prep for CheckPoint E85.30 that is macOS12 supported, I did the following:
ACTIONS:
- Booting to recovery produced "no admin error"; To bypass the "no admin error", we booted back to OS and turned off Filevault disk encryption. From terminal:
- su $ADMIN
#(or other filevault2 user found under Jamf - Computers - Computername - Disk Encryption) - sudo fdesetup disable
- sudo sysadminctl -adminUser $ADMIN -adminPassword - -secureTokenOn $USER -password -
#(where $ADMIN = filevault2 user & $USER = username)
- sudo fdesetup enable
- sudo diskutil apfs updatePreboot /
- Added admin users as secure token users and re-enabled disk encryption using command above
sudo sysadminctl -adminUser $ADMIN -adminPassword - -secureTokenOn $OTHER -password - - Booted to recovery and reduced security to allow 3rd party extension
- Allow user management of kernel extensions from identified developers
- Allow remote management of kernel extensions and automatic software updates
