@bmcdade anything in particular preventing you from updating to the latest versions of Connect? At the very least, Connect 2.1.0 was the first universal build with Apple Silicon support (including authchanger).
Additionally, from recovery you have the ability (through Terminal) to restore the authorization database back to original: Restoring the Authorization Database
@bmcdade anything in particular preventing you from updating to the latest versions of Connect? At the very least, Connect 2.1.0 was the first universal build with Apple Silicon support (including authchanger).
Additionally, from recovery you have the ability (through Terminal) to restore the authorization database back to original: Restoring the Authorization Database
Hi Mike,
Thanks for your response and wish I saw it a few minutes sooner.. I was searching for the wrong terms I guess about restoring the Auth DB.. I'm working on seeing what would happen if one of the users with the M1 just happened to do an upgrade, or if we would allow it. I'm going reinstall clean and do the same setup to see if I can break out of the loop if there is an accidental update. I will start to look at the later version, since we did have issues of how we were using JCL with Okta,
Hi Mike,
Thanks for your response and wish I saw it a few minutes sooner.. I was searching for the wrong terms I guess about restoring the Auth DB.. I'm working on seeing what would happen if one of the users with the M1 just happened to do an upgrade, or if we would allow it. I'm going reinstall clean and do the same setup to see if I can break out of the loop if there is an accidental update. I will start to look at the later version, since we did have issues of how we were using JCL with Okta,
Also as an update, seems that after doing a wipe of the M1 hardware, re-installing JCL again that I no longer get this error, it's hard to reproduce without the update happening. Seems this might be something triggered via the upgrade process.
Hello bmcdade,
When you upgrade an apple silicon Mac to 11.5.2, Old Rosetta 2 is no longer compatible to the changed frameworks of the new OS version, therefore it is disabled and behaves as removed. Usually the users are prompted for the update to update the matching version of Rosetta 2 for the OS version. As it is updated, a standard user should be able to initiate the update.
If you want to update it proactive, you can use the command line after the software update (which is the same as when you want to install it initially):
sudo /usr/sbin/softwareupdate –install-rosetta –agree-to-license
Hope this will help.
-Samstar777
Hello bmcdade,
When you upgrade an apple silicon Mac to 11.5.2, Old Rosetta 2 is no longer compatible to the changed frameworks of the new OS version, therefore it is disabled and behaves as removed. Usually the users are prompted for the update to update the matching version of Rosetta 2 for the OS version. As it is updated, a standard user should be able to initiate the update.
If you want to update it proactive, you can use the command line after the software update (which is the same as when you want to install it initially):
sudo /usr/sbin/softwareupdate –install-rosetta –agree-to-license
Hope this will help.
-Samstar777
Thanks Samstar for the explanation on this. It does seem to make sense.
The unit did come with a version of 11.5 which was obviously lower than 11.5.2. Our Connect Login installation does a check for Rosetta installed, and if the unit is an M1 without Rosetta, then we trigger the install manually via a script with the same commandline call that you showed. I can't really test this much more since as I said when I did a wipe of the hardware, and fresh install from recovery mode, then added back the Jamf Connect, it still worked. I guess I might have to wait until Apple does another release, and see if that update breaks Jamf Connect Login again. I guess otherwise we would need to disable updates for those M1 users, and use scripts to apply updates.
Thanks again for your help.