Skip to main content
Solved

M1 latest Big Sur update broke Jamf Connect Login

  • August 30, 2021
  • 5 replies
  • 38 views
bmcdade
Forum|alt.badge.img+5

I am doing some tests with our installation and workflow on the new M1 with Big Sur.  It seems that it was fine installing our older version of Jamf Connect Login (2.0.4) from self service as long as I would check for Rosetta on the hardware first, and then install it if it wasn't present.  All seemed well until I decided to do the latest OS update for Big Sur, and after the restart I am getting the following Error : Unrecoverable error: SecurityAgent was unable to create requested mechanism JamfConnectLoginLoginUI".  So now the machine is bricked as it's stuck unable to run the login screen.

I haven't figured out a way to get around this without reformatting the device, the problem is it won't boot, and when I am in recovery mode with terminal, the authchanger program won't run due to the an incompatible CPU type (yes authchanger is only for x86, yet in recovery it's stuck to arm64.  Anyone else think of some way I could get reset and remove JCL from the Login window without the use of authchanger?

Best answer by mikevandelinder

@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

    5 replies

    M
    Forum|alt.badge.img+15

    @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
    bmcdade
    Forum|alt.badge.img+5
    • bmcdade
    • Author
    • Contributor
    • August 30, 2021

    @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, 

    bmcdade
    Forum|alt.badge.img+5
    • bmcdade
    • Author
    • Contributor
    • September 3, 2021

    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.

    Samstar777
    Forum|alt.badge.img+11
    • Samstar777
    • Valued Contributor
    • September 8, 2021

    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

    bmcdade
    Forum|alt.badge.img+5
    • bmcdade
    • Author
    • Contributor
    • September 9, 2021

    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.

    Terms & ConditionsCookie settingsAccessibility statement