+23Anybody else noticing that the macOS 13.2.1 update is causing machines to boot to system recovery? I had 1 user report that it booted to recovery, but they were able to reboot it again and it was fine. Another user had to enter the recovery key.
I think they were both m1 Macs, and used Nudge (current version) to initiate the update process.
+23thank you, glad to know it's not a gremlin in our environment.
+16We have had quite a few Apple silicon Macs boot into recovery after the 13.2.1 update in our environment. Hoping to open a bug with Apple.
+8I didn't think it was recovery, but authorization. This happens when you force an update using certain MDM commands, an unauthorized reboot without an escrowed bootstrap token and the end user has to authorize the update and reboot.
I just wasn't surprised that there was a super user unfriendly procedure to it, so I just assumed that's what happened.
+1Hopefully I don't get in trouble for posting here, as we're using an alternative to Jamf as our Apple MDM provider, but I just wanted to say we are experiencing the same problem. Thus far about 1/3 of our (admittedly small, < 100 machines) Macs have ended up on the recovery screen when rebooting. Which, in a fully remote company, is a problem...
+8Hopefully I don't get in trouble for posting here, as we're using an alternative to Jamf as our Apple MDM provider, but I just wanted to say we are experiencing the same problem. Thus far about 1/3 of our (admittedly small, < 100 machines) Macs have ended up on the recovery screen when rebooting. Which, in a fully remote company, is a problem...
But is it saying recovery or forgotten password, or is it saying "Authorize"?
+1
Which is correct, we _have_ restricted access to Recovery, on purpose. The unique recovery password for each machine is stored with our MDM provider.
Selecting 'Restart' just brings them back to this lock screen.
When we have provided the Recovery password for their machine to each user, they have been able to progress through this step, complete the update, and load into their normal user. But of course handing out recovery passwords for their machines to 1/3 of our userbase isn't great, given the _point_ was to prevent them wiping the machine in circumstances when we didn't want to allow that.
But the machines we initially tested the update on _didn't_ do this. My machine was fine, as was that of my colleague in MDM admin, and several others.
The vast majority of our users are on Apple Silicon, though we do still have 5 or so on Intel. None of whom have experienced the problem. Some of our M1 users have upgraded with no recovery or issues.
Something we _have_ noticed is that _all_ of the affected machines are in Apple Business Manager, although not all of the ABM-registered machines are affected. I mention that because we have a number of machines in Europe that were purchased directly rather than via ABM (UK). Given the percentage failure rate so far, I would have expected some of those to see the same problem, unless something about them not being in ABM means the recovery password can't apply or something.
+1
Which is correct, we _have_ restricted access to Recovery, on purpose. The unique recovery password for each machine is stored with our MDM provider.
Selecting 'Restart' just brings them back to this lock screen.
When we have provided the Recovery password for their machine to each user, they have been able to progress through this step, complete the update, and load into their normal user. But of course handing out recovery passwords for their machines to 1/3 of our userbase isn't great, given the _point_ was to prevent them wiping the machine in circumstances when we didn't want to allow that.
But the machines we initially tested the update on _didn't_ do this. My machine was fine, as was that of my colleague in MDM admin, and several others.
The vast majority of our users are on Apple Silicon, though we do still have 5 or so on Intel. None of whom have experienced the problem. Some of our M1 users have upgraded with no recovery or issues.
Something we _have_ noticed is that _all_ of the affected machines are in Apple Business Manager, although not all of the ABM-registered machines are affected. I mention that because we have a number of machines in Europe that were purchased directly rather than via ABM (UK). Given the percentage failure rate so far, I would have expected some of those to see the same problem, unless something about them not being in ABM means the recovery password can't apply or something.
Whoops, sorry, that was supposed to be in reply to @piotrr
+8
Which is correct, we _have_ restricted access to Recovery, on purpose. The unique recovery password for each machine is stored with our MDM provider.
Selecting 'Restart' just brings them back to this lock screen.
When we have provided the Recovery password for their machine to each user, they have been able to progress through this step, complete the update, and load into their normal user. But of course handing out recovery passwords for their machines to 1/3 of our userbase isn't great, given the _point_ was to prevent them wiping the machine in circumstances when we didn't want to allow that.
But the machines we initially tested the update on _didn't_ do this. My machine was fine, as was that of my colleague in MDM admin, and several others.
The vast majority of our users are on Apple Silicon, though we do still have 5 or so on Intel. None of whom have experienced the problem. Some of our M1 users have upgraded with no recovery or issues.
Something we _have_ noticed is that _all_ of the affected machines are in Apple Business Manager, although not all of the ABM-registered machines are affected. I mention that because we have a number of machines in Europe that were purchased directly rather than via ABM (UK). Given the percentage failure rate so far, I would have expected some of those to see the same problem, unless something about them not being in ABM means the recovery password can't apply or something.
Oh, oh man, I am so sorry, that really sucks. I hadn't expected you to block recovery on purpose.
I don't mind if users wipe their machines, since my whiteglove boot-up to ADE/ABM machines is down to 20 minutes, all they would lose is their own unsynced data and some time. So I have seen no reason to restrict users from the recovery environment. In fact, they might need it. Our machines are almost all prestage ADE locked so they cannot be re-used for anything else, you cannot set them up without an internet connection and if they get that, they go straight to enrollment.
Yep! Seeing the same issue with our various Macs. Seems like a hit or miss... Some Macs updated perfectly fine, others entered recovery. We are also zero-touch deployments, ABM and Jamf Pro. Will report issue to Apple.
+7Oh, oh man, I am so sorry, that really sucks. I hadn't expected you to block recovery on purpose.
I don't mind if users wipe their machines, since my whiteglove boot-up to ADE/ABM machines is down to 20 minutes, all they would lose is their own unsynced data and some time. So I have seen no reason to restrict users from the recovery environment. In fact, they might need it. Our machines are almost all prestage ADE locked so they cannot be re-used for anything else, you cannot set them up without an internet connection and if they get that, they go straight to enrollment.
Perhaps a bit off topic, but ADE is pretty easy to circumvent. In essence, macOS disable csr and fiddle with the system files during setup. iOS can also be bypassed easily on any version by restoring a blank generic backup before network is connected. The only good way to prevent unauthorized use is to enable activation lock centrally, but then you have the downside of having to administer recovery lock bypass codes, and also the pain of accidentally deleteing the device from JAMF so the bypass code is lost. In our case, we'd rather lose a few devices before going though that administrative nightmare.
+11We are also seeing this. It's EXTREMELY hit or miss. All machines exhibiting this behavior are apple silicon. We are an ADE zero touch shop as well, but I feel that's a false flag.
+10We are also seeing this. It's EXTREMELY hit or miss. All machines exhibiting this behavior are apple silicon. We are an ADE zero touch shop as well, but I feel that's a false flag.
Macadmins confirmed it's hitting Intel as well (have had 1x Intel, majority Silicon)
+6Fixed in 13.3.
If you have a Mac that's currently stuck, boot into Internet Recovery, which will allow you to install 13.3.
I've already recovered 1 Mac this way.
+1Had this issue with 13.2.1. with TWO different systems. One Apple Silicon, one Intel. I did a full reinstall in 13.2.1 on the Intel which booted me back into recovery twice... once in recovery, a regular restart allowed me to work fine. I just restarted when I got to recovery on the Apple Silicon system and it booted fine without the OS reinstall. And this same thing happened again with the 13.3 update with both systems, but restarted and systems are functioning fine.
We have seen two devices both Silicon.
+8Perhaps a bit off topic, but ADE is pretty easy to circumvent. In essence, macOS disable csr and fiddle with the system files during setup. iOS can also be bypassed easily on any version by restoring a blank generic backup before network is connected. The only good way to prevent unauthorized use is to enable activation lock centrally, but then you have the downside of having to administer recovery lock bypass codes, and also the pain of accidentally deleteing the device from JAMF so the bypass code is lost. In our case, we'd rather lose a few devices before going though that administrative nightmare.
And for me, I'd rather users circumvent ADE or restoring their private backups on company phones, because we have conditional access, so they're not going to be able to work on those devices until they register them properly.
Sure they could sell/steal them, but that would also end badly for them.
+6We've had several machines (Intel and Apple Silicon) with this problem, and restarting from recovery just brought them back to recovery.
Since 13.3 came out, we've used Internet Recovery on the stuck machines to install that update. For some reason, doing it this way takes a very long time (over an hour), including lots of time on blank screens, but when it's done, it booted normally.
Anyone stuck on a white window after a Mac OS 13.x update ?
Filevault enabled and I5 or M1, Forced to go through recovery
+1Anyone stuck on a white window after a Mac OS 13.x update ?
Filevault enabled and I5 or M1, Forced to go through recovery
I haven't gotten stuck at that particular screen, but what happens if you just restart once in recovery? Are you sent back to the white screen or does it boot normally?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.