Can someone help me understand the issue I am having with updating a new Macbook Air that has the T2 chip in it from 10.14.1 to 10.14.2. We have a software update server using NetSUS and when our users try to upgrade, they get the message below. Updating then fails when they try that. The only way to get back in is to select the startup disk and go back to 10.14.1.
I think this has to do with the T2 chip, but not sure how I can get around this.
I'd be curious to see if you set your update server to Apple's servers if it would work, we aren't seeing that issue but we use Apple's SUS.
I did see this when I booted to a freshly-created USB boot disk to install Mojave, and it fails because we don't have any active network at that point thanks to 802.1x on Ethernet. I'd have to whitelist the adapter to make this work.
We saw this when using NetSUS paired with a Jamf policy to install updates if available to the device. When pushed by that Jamf policy this would happen on the newer Mojave T2 devices.
Scoped that policy to High Sierra devices only, excluded Mojave.
Set Mojave to auto update while pointed to our NetSUS. This issue stopped.
However, new issue has popped up for the 15" 2018 MBPro's. Stuck in a reboot loop after 10.14.2
@MTFMRCO - We do pretty much the same thing. NetSUS to manage the updates and JAMF to push them. If you set Mojave to auto update, do your users need admin rights or credentials to upgrade? We also have some 15" MBPro's in our environment so at this point I am going to hold off on letting users upgrade until I have found out a better process. Let me know if you figure this out!
@danshaw No, admin rights not required. We flipped it on and let the native window of installing updates within 7 days do it's thing. Worked for 10.14.1, no problem. Sometimes users would initiate themselves through System Prefs>Software Updates.
The 15" that took 10.14.2 is still toast. Reset SMC, PRAM, no change. Now, if it gets unplugged from power the device immediately just shows as having no batter charge. Touchbar has never lit up once since taking the update.
We have the same issue on MBP update from 10.14.3 to 10.14.4.
Went into Startup Security Utility, changed the Secure Boot to "No Security" did NOT help.
Although users can just click "Update" to get it rolling, we do want to have a seamless, smooth deployment to eliminate popups that need user interactions. Any ideas what else can we do?
We had the exact same problem and were finally able to find a solution to it. I hope this helps somebody else.
This problem seemed to only occur on T2 macs as you mentioned. We have another issue that is very similar to what was happening here: https://www.jamf.com/jamf-nation/discussions/30337/macbook-pro-2018-mojave-upgrade-fails
We were able to solve both of these issues by changing the way restarts were performed. If we performed a restart from JAMF's policies section, we'd have the "internet connection required" error for Mojave and the startup disk issue with general updates. Same results if we used "sudo shutdown -r".
According to Apple Support, T2 chips require a shutdown command after upgrades rather than a reboot. We tested this and it seemed to be true.
"sudo shutdown -h +10" calling this command in a script after installing updates were performed fixed both of our issues. We allow the user to defer the installation of the update and then let them know that the machine will restart in 10 minutes. Manually restarting seems to be okay as well.
I've seen this on a few T2 Macs recently, particularly some headless 2018 Mac Minis. They also seem to end up at the setup assistant from time to time, although this is inconsistent.
Wouldn't "sudo shutdown -h +10" cause a shutdown and not a restart, or am I missing something? The aim in our environment is to have the machine restart after installing updates rather than shut down. If you've found a way to reboot them instead that would be awesome!
In our experience this command actually brings the machine back online if ran after an update. In my testing the machine will shutdown and automatically turn back on. I initially shared the same concerns as you but was able to confirm positive results in my testing.
Try it out and let me know how it goes! Would love to hear others experience with it.
@angle.52 @jtrant Thanks for bringing the T2-update-shutdown requirement to attention here; if you need this as part of your workflow - and it only makes sense to integrate this if Apple's introduced this functional requirement - you can upvote this feature request:
It seems a bit out of date and may now be considered part of PI-006891 [Software Update policy payload does not support shutdowns] per ponyboy's comment. But it can't hurt to express your voice whether it's a feature or bug (and as far as I know Jamf doesn't have a way to vote on what bugs should be fixed... )
We have a few iMac Pro's here (T2 chip) that are affected by this. I've noticed that after the past couple security updates, I have to physically drive over to the office on the weekend to click "Update" on the "startup disk software update" message for the reboot to complete.
Will try the reboot command that @angle.52 mentioned above next time... hopefully it will save me a trip!
@Cayde-6 Well considering the circumstances here that I just described, that wouldn't help me much. I'd still have to make a trip out to the office to complete the update, or stick around after hours.
What material are you referencing when you say that softwareupdate says shutdown only? Why would they have a reboot flag baked into it if that were the case? I just updated a whole bunch of machines on the weekend using this command, and they came back up fine. Only the T2 macs had the issue the OP described.
#!/bin/sh # install all updates (force reboot since -R flag does not work) softwareupdate -i -a -R && reboot now
Sorry missed this in the comments from the author: "Just wanted to let you know that I did some more testing today on Catalina. I made some updates to the script with some other bug fixes. I can confirm that it works in Catalina."
Since the issue seems to be with T2 equipped Macs, are you scoping this just to those Macs and still using the Software Updates payload for the rest?
Just cause I'm a little slow. I currently have updates set to auto run in JAMF. Well, I must, cause the devices constantly try and then get stalled with the error message that started this thread. What I should do however is turn that off (someone please tell me how) and then use the script here https://github.com/bp88/JSS-Scripts/blob/master/AppleSoftwareUpdate.sh and assign it to the device(s) when I want to run an update, correct? Or do you guys scheduled the scipt as an ongoing thing, like a check-in?
In terms of the updates, if I go to Computer Management...App Updates, this setting is just for apps from the store, no OS options. If I search the entire inventory, then click the "Action" button...Send Remote Commands...Update OS... Do I select "
Download the update for users to install"? I recall last summer selecting "Download and install the update, and restart computers after installation" Possibly that is why they keep chosing to apply the OS update during the middle of a lesson? ;-)
Follow this guide to restore T2 chip firmware: https://support.apple.com/guide/apple-configurator-2/revive-or-restore-mac-firmware-apdebea5be51/mac
That's the only way I could get around this problem. Backup your data first.
This problem was addressed in a recent JAMF Upgrade. You'll need to upgrade to JAMF 10.23.
[PI-006891] Fixed an issue that caused computers with the T2 Security Chip to restart instead of shutting down and fail to properly complete the update when using the Software Update payload to upgrade macOS.