Scripted Big Sur Update fails into "Update Startup disk" Screen

[daniel_blohm]

Hi Jamf Nation,

I deployed a policy in Jamf which executes a script which essentially runs:

/Applications/Install macOS Big Sur/Contents/Resources/startosinstall --agreetolicense --forcequitapps

On most machines this works flawlessly and after some 30 minutes or so the machine is on Big Sur.

But on some machines it gets fuzzy. Sometimes the installer runs but.. just ends. Then, if started again the machine after some minutes reboots as expected. But then it lands in the recovery console saying:

A software update is required to use this startup disk

Clicking on "Update" just gets the user back to the same screen after a few seconds of showing the boot apple logo.

The only valid choice they can make is "Choose Start-Volume", Logging in with their password to unlock the drive and do a restart into macOS Catalina.
This is completely repeatable on the same, but not reproducable on another machine. If we start the "Install macOS Big Sur.app" from the finder after giving the user admin rights, the assistant comes up, system reboots and installs Big Sur as it should.

So what's the difference here between the startosinstall command and the Installer.app?

I hope someone here can shed a little light on this.

Regards
Daniel

[DBrowning]

They will need to make sure they are connected to internet. We've seen the same. There is a lost of internet when its trying to run a bridgeOS update I believe it is.

[dan-snelson]

Thanks for posting this, @daniel.blohm.

We're seeing the same workflow as described in the section of the following article:
https://support.apple.com/en-us/HT208198

During startup, your Mac verifies the integrity of the operating system (OS) on your startup disk to make sure that it's legitimate. If the OS is unknown or can't be verified as legitimate, your Mac connects to Apple to download the updated integrity information it needs to verify the OS. This information is unique to your Mac, and it ensures that your Mac starts up from an OS that is trusted by Apple. If FileVault is enabled while your Mac is attempting to download updated integrity information, you're asked to enter a password to unlock the disk. Enter your administrator password, then click Unlock to complete the download. If the OS doesn't pass verification: macOS: An alert informs you that a software update is required to use this startup disk. Click Update to open the macOS installer, which you can use to reinstall macOS on the startup disk. Or click Startup Disk and choose a different startup disk, which your Mac will also attempt to verify.

I have an open issue with AppleCare, 20000062150884, and am waiting on users to provide logs.

[daniel_blohm]

So, when I cumulate the info from @DBrowning and @dan-snelson it could be that during the restart the MacBooks loose their internet connection and therefor do not pass the verification?

Could it be that when the user lands in the "Update" Screen this fails because the user is NOT a local admin?
What I cannot figure out though is why does it always (and I mean ALWAYS) work when using the Install wizard like a "normal" end user would? The thing with the internet connection is, at the moment everyone is at home. So the connection would be over WiFI in 90% I would say. Even if there is a connection loss during reboot. Why am I not able to reproduce this? I am at home too always on WiFi but in my testing it always works. I don't think that I have a special setup and even less that any of my users have any special setup. It's a WPA Personal Key and that's it.

According to your article it seems that the OS is "unknown". So now I'm thinking maybe the package itself (created with installinstallmacos.py) could be the culprit here?

[dan-snelson]

@daniel.blohm

I haven't confirmed if the affected computers are loosing their Internet connection during restart.

We've provided nearly 3 GBs of logs to Apple and I'll update this thread when we know more.

(We're seeing about a 20 percent "failure" rate.)

[dan-snelson]

Happy Monday, @daniel.blohm!

An investigation with Apple Product Engineering has been initiated via AppleCare support.

We're ensuring that users are running Sophos Endpoint 10.0.2 and Palo Alto GlobalProtect (5.1.7-20) prior to upgrading via Self Service.

[daniel_blohm]

Hi @dan.snelson Good to hear that.
On the anti-malware side we have Microsoft Defender. We have no checking before running here.