startosinstall sometimes does not run

[patgmac]

We have an intermittent problem where the full screen message appears for the user when the install is starting, but the machine just sits there with the full screen message forever.

Workaround: Force quit the FS message and run the policy again. In most cases, it will work the 2nd time. We've added a message which instructs the user to force quit if it doesn't reboot in 5 minutes.

Is there some way we can confirm the command kicked off the way it's supposed to, so that the script can try again if it didn't kickoff properly?

[Hacksore]

@patgmac I've also seen this with a few of our devices. Something has to be wrong with the startosinstall binary causing it to get stuck randomly.

[Genesis2kx]

I'm trying to upgrade 10.12.6 client to 10.13.3 High Sierra with this script and get stuck on the Full screen message as well "Please wait as we prepare your computer for macOS High Sierra..." I end up force quitting but running it again doesn't seem to help and i'm not sure where the hangup is.

JSS logs say complete, but don't show anything useful.

[STEP 1 of 4] Executing Policy Install 10.13.3 High Sierra [STEP 2 of 4] Running script SS: Install 10.13.3 - New... Script exit code: 0 Script result: Power Check: OK - AC Power DetectedDisk Check: OK - 85557624832 Bytes Free Space Detectedmkdir: /usr/local/jamfps: File existsLaunching jamfHelper as FullScreen...Launching startosinstall... [STEP 3 of 4] [STEP 4 of 4]

Any ideas @kc9wwh ?

[patgmac]

@Genesis2kx Can you get a hold of the /var/log/install.log from that machine?

[kc9wwh]

@patgmac - So I did see this a few times testing on VM's but never on a physical machine and it was only on 10.10 VM's.

What macOS version are you seeing this on? Is it physical or virtual?

I'm a little hesitant to add a check in the script, just cause the installer goes so fast I'd be worried that it would finish and the script would still be running, which then causes Self Service to error out when trying to close a running script as part of the reboot process.

But please send along your install.log files and we'll see what is going on. I'm pretty sure it has to do with the LaunchAgent I am injecting in the last update. Assuming there is something slightly different for other OS versions that cause it to trigger properly.

[Hacksore]

@kc9wwh Actually, we are not invoking the FV authenticated reboots in my fork of the script. With that said we still run into a very small set of systems that get stuck on jamfhelper.

We are taking physical systems from 10.12.6 to 10.13.2 if that information helps at all.

[kc9wwh]

@Hacksore - Do you see the startosinstall binary starting the process in the /var/log/install.log?

Also, can you check the checksum on the files after they are staged on the system? Primarily the InstallESD.dmg and startosinstall binary. Below are the commands and my output, curious how it compares...

roskos-mbp:~ josh.roskos$ openssl dgst -sha256 /Applications/Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/InstallESD.dmg 
SHA256(/Applications/Install macOS High Sierra.app/Contents/SharedSupport/InstallESD.dmg)= 438fc19055e56ac90fb485796d3aacc4059d241d79bc5c303220c4c2468a1f9d
roskos-mbp:~ josh.roskos$ openssl dgst -sha256 /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/startosinstall 
SHA256(/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall)= 2c77315776221df8cacdae64aacaaef2ce640926cf2839298b730ec2e465eea9

[Genesis2kx]

@patgmac I found out after reviewing the install.log on my machine that installESD.dmg file couldn't be mounted because we have a JAMF config profile in place to prevent disk images from mounting. After i excluded the machine it went through. It did show a FV2 authentication screen after it rebooted during the upgrade process.

[Palgus]

I am seeing the above behavior. Physical machines. 10.12.6 -> 10.13.3. The first time we run the policy (self service) with the install script it "completes" but just sits at the JAMF Helper Screen and does not reboot. I Command-Q and "reinstall" the same policy from Self Service, the computer reboots and does the upgrade to 10.13.3.

Looking in the install.log, I can see it canceling the install here I think:

Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: MiniSoftwareUpdate: Asset caching error when looking up URL <MSUPackage: 0x7fe2fa757520>: AssetCacheLocatorService: cancelled

Below is what I have in the log

Feb 27 12:02:06 MN-C02M508UF5YV osinstallersetupd[779]: OSISChunkedDownload loaded...
Feb 27 12:02:06 MN-C02M508UF5YV osinstallersetupd[779]: OSISSoftwareUpdateController: Using catalog (source: GM Default): https://swscan.apple.com/content/catalogs/others/index-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog
Feb 27 12:02:06 MN-C02M508UF5YV osinstallersetupd[779]: mountDiskImageWithPath: /Applications/Install macOS High Sierra.app/Contents/SharedSupport/InstallESD.dmg
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: OSISSoftwareUpdateController: Loaded catalog https://swscan.apple.com/content/catalogs/others/index-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog (548 products)
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Mounting disk image complete, results dict = {
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Mount point /Volumes/InstallESD
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Using product <OSISSharedSupportProduct: 0x7fe2fa2aa710> at distance 10
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Using product <OSISInstallMediaProduct> based on media at /Volumes/InstallESD at distance 5
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Failed to load BridgeOSInstall.framework: dlopen(/System/Library/PrivateFrameworks/BridgeOSInstall.framework/BridgeOSInstall, 1): image not found
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: Current version of BridgeOSInstall.framework doesn't have the latest API, assuming machine does not have bridgeOS
Feb 27 12:02:07 MN-C02M508UF5YV osinstallersetupd[779]: osinstallersetupd registered client
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Using product <OSISCollectionInstallProduct: 0x7fe2fa255bd0> at distance 10
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Is solid state disk returned: -69808
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Helper tool loaded
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Install was requested to a disk that was not evaluated. Blocking on evaluation.
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: No available package ref for compatibility update. Ignoring.
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Specifier (<PKPackageSpecifier>:
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: No available package ref for compatibility update. Ignoring.
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Required package references: (
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: No available package ref for compatibility update. Ignoring.
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Unable to get fs for (null)
Feb 27 12:02:08 --- last message repeated 5 times ---
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: OSISDownloadOperation: totalEstimate=396.000000, significantDownload=1
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Operation queue started
Feb 27 12:02:08 MN-C02M508UF5YV osishelperd[800]: Privileged helper tool loaded.
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Using product PKSecureNetEnabledProduct <file:///macOS%20Install%20Data/> at distance 5
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Using product <MSUProduct: key=091-32390, name="(unknown)", evaluated=NO, installable=NO, staged=NO> at distance 25
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: Skipping bridgeOS update because BridgeOSInstall.framework doesn't exist on the boot volume
Feb 27 12:02:08 MN-C02M508UF5YV osinstallersetupd[779]: MiniSoftwareUpdate: Asset caching error when looking up URL <MSUPackage: 0x7fe2fa757520>: AssetCacheLocatorService: cancelled

Feb 27 12:06:08 MN-C02M508UF5YV osinstallersetupd[1181]: OSISChunkedDownload loaded...
Feb 27 12:06:08 MN-C02M508UF5YV osinstallersetupd[1181]: OSISSoftwareUpdateController: Using catalog (source: GM Default): https://swscan.apple.com/content/catalogs/others/index-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog
Feb 27 12:06:08 MN-C02M508UF5YV osinstallersetupd[1181]: mountDiskImageWithPath: /Applications/Install macOS High Sierra.app/Contents/SharedSupport/InstallESD.dmg
Feb 27 12:06:09 MN-C02M508UF5YV osinstallersetupd[1181]: OSISSoftwareUpdateController: Loaded catalog https://swscan.apple.com/content/catalogs/others/index-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog (548 products)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Mounting disk image complete, results dict = {
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Mount point /Volumes/InstallESD
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Using product <OSISSharedSupportProduct: 0x7fafd7442300> at distance 10
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Using product <OSISInstallMediaProduct> based on media at /Volumes/InstallESD at distance 5
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Failed to load BridgeOSInstall.framework: dlopen(/System/Library/PrivateFrameworks/BridgeOSInstall.framework/BridgeOSInstall, 1): image not found
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Current version of BridgeOSInstall.framework doesn't have the latest API, assuming machine does not have bridgeOS
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: osinstallersetupd registered client
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Is solid state disk returned: -69808
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Using product <OSISCollectionInstallProduct: 0x7fafd4fc3730> at distance 10
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Helper tool loaded
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Install was requested to a disk that was not evaluated. Blocking on evaluation.
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No available package ref for compatibility update. Ignoring.
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Specifier (<PKPackageSpecifier>:
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No available package ref for compatibility update. Ignoring.
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Required package references: (
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No available package ref for compatibility update. Ignoring.
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Unable to get fs for (null)
Feb 27 12:06:10 --- last message repeated 5 times ---
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: OSISDownloadOperation: totalEstimate=396.000000, significantDownload=1
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Operation queue started
Feb 27 12:06:10 MN-C02M508UF5YV osishelperd[1184]: Privileged helper tool loaded.
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Using product PKSecureNetEnabledProduct <file:///macOS%20Install%20Data/> at distance 5
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Using product <MSUProduct: key=091-32390, name="(unknown)", evaluated=NO, installable=NO, staged=NO> at distance 25
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Skipping bridgeOS update because BridgeOSInstall.framework doesn't exist on the boot volume
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieving 7 packages (0.000 GB)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify AppleDiagnostics.dmg
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.dmg.AppleDiagnostics (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/AppleDiagnostics.dmg)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Installing timeout for incompatible app list
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.pkg.CompatibilityUpdate (http://swcdn.apple.com/content/downloads/29/47/091-32390/h1xqsjbjljp2t42yznlu1xfireijxahftc/OSX_10_13_IncompatibleAppList.pkg)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify InstallInfo.plist
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.plist.InstallInfo (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/InstallInfo.plist)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify BaseSystem.chunklist
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.chunklist.BaseSystem (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/BaseSystem.chunklist)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify AppleDiagnostics.chunklist
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.chunklist.AppleDiagnostics (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/AppleDiagnostics.chunklist)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify BaseSystem.dmg
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.dmg.BaseSystem (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/BaseSystem.dmg)
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: No native mechanism to verify InstallESD.dmg
Feb 27 12:06:10 MN-C02M508UF5YV osinstallersetupd[1181]: Retrieved package com.apple.dmg.InstallESD (linkfile:///Applications/Install%20macOS%20High%20Sierra.app/Contents/SharedSupport/InstallESD.dmg)
Feb 27 12:06:11 MN-C02M508UF5YV osinstallersetupd[1181]: Skipping preflighting since we're not on supported hardware
Feb 27 12:06:11 MN-C02M508UF5YV osinstallersetupd[1181]: Starting personalization
Feb 27 12:06:11 MN-C02M508UF5YV osinstallersetupd[1181]: Skipping personalization because OSPersonalization.framework doesn't exist on the boot volume
Feb 27 12:06:11 MN-C02M508UF5YV osinstallersetupd[1181]: Operation queue succeeded

[scifiman]

I am seeing this issue as well with a forked/modified copy of your script. I'm trying to go from 10.12.6 to 10.13.6. Nothing is showing up in the install.log that would be pertinent to this. Once the process starts, it doesn't seem like the install.log even gets touched. The startosinstall process is just stuck in a "sleeping" state. If I run the command manually as root from Terminal (either locally or via ssh), the startosinstall executable just hangs after giving me the notice with the --agreetolicense and the option to quit now if I don't agree. I'm thinking there may be something up with the install media, but I'm not sure.

I am now going back to your original (2.6.1) to see if it is something I have changed. With your original, I am already seeing 2 other issues though. First, it seems your script will fail if there is a space in the download trigger name. Perhaps it's not properly quoted? Second, it seems to get stuck in a download loop as if it's not able to break the loop after 3 failures.

[UESCDurandal]

I've encountered this issue yesterday when going from 10.13.6 to 10.14.1 The jamfHelper splash page stays on the screen forever. Quitting jamfHelper and re-running the Jamf policy a second time seems to work.

[krispayne]

We get this randomly on some machines when we're upgrading to various versions.

This currently happens on 10.13.6, 10.14, and 10.14.1 for us. FWIW, I believe all upgrades have been from 10.12.

The only thing we notice is that the install.log stops running and only says this:

Nov 13 11:18:14 macname startosinstall[27336]: OSInstallerSetup build: 1
Nov 13 11:18:14 macname startosinstall[27336]: No compatibility bundle on this version of macOS. Will assume compatible.

Typically, we try again via Self Service and if it works, yay! if not, then we run the policy via sudo jamf policy -id ### and it works right away. The constant here seems to be running it from Self Service. Every time we run it manually, the process seems to work.

We just tested again and bypassed self service altogether and the script worked the first time. Not definite evidence of self service being the issue, but more information, nonetheless.

[bgrande12]

Anyone else running into the same issue as @krispayne and has a solution? I'm seeing the same type of issue and messages in install.log for the 10.14.1 installer, but not the 10.14 one. Issue is independent of this script because I get the same thing when I run the startosinstall --erasedisk command in terminal

[krispayne]

We also find that if the system is completely up to date, it doesn’t have the issue. I.e. all security updates, etc are installed prior to initiating the upgrade from self service.

[sdpalmer]

In my case I found why the macOSUpgrade script was hanging indefinitely with the full screen message by force quitting the message and running the startosinstall command manually. The results of the command were:

root on ServiceTag$ /Applications/Install\ macOS\ Mojave.app/Contents/Resources/startosinstall --agreetolicense --nointeraction

By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.

If you do not agree, press CTRL-C and cancel this process immediately.

Preparing to run macOS Installer...

The installer could not verify the disk. Open Disk Utility, then run First Aid.

Unfortunately, I didn't think to do an echo $? to see what the exit code was.

This is even though I had just wiped my MacBook Pro and installed a fresh image with macOS 10.12 for testing the upgrade.

I hadn't thought about this because we haven't done many in place upgrades with 10.13 or 10.14 yet, but I suppose this makes sense that the installer is checking the disk before converting to APFS.

After running First Aid I got the following error:

This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.

So it appears the macOSUpgrade script doesn't know how to handle this error and just exits leaving the full screen message in place.

I would suggest at least monitoring for unknown exit conditions of the startosinstall command and taking down the full screen message (and removing the launch daemons) if an error condition is met, echoing the error so it is stored in the policy log, and display a message to the user to contact their local IT Admin.

Additionally, it might be good to preemptively scan the disk at the very beginning of the script with diskutil verifyDisk and if it reports any errors fail out before even downloading the installer and attempting to install the Launch Daemons and running startosinstall. Then display a message to the user to contact their local IT Admin for assistance with repairing the disk before proceeding.

[kc9wwh]

@sdpalmer we can't monitor for that. The script is setup to exit before the upgrade actually completes otherwise the startosinstall binary will try to restart while the script is still running creating additional issues. We rely on the binary to close the jamfHelper windows once it completes so I think this would be more an Apple feature request at this point that when the binary does fail, that is still adhears to the killPID parameter.

[sdpalmer]

@kc9wwh Understood on the startosinstall command.

However, since we know startosinstall will stop if the disk can't be verified, couldn't the diskutil (or even fsck) command I mentioned be run before anything else?

This would intercept this possible failure before even running the startosinstall command. Both of those tools should return an exit code of 0 on success which means the script could proceed with the install otherwise for a non-zero exit code report an error to the user (and for the policy logs) and exit the upgrade script.

[Genesis2kx]

Is there a way that the JSS logs can show this part of the script that you would normally see if starttoinstall is run manually. For me There's been hangups at the preparation stage on some machines and being able to see the output of startoinstall in the JSS would be helpful. Sample output below.

By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
Preparing to run macOS Installer...
Preparing: 0.2%
Preparing: 7.0%
Preparing: 9.4%
Preparing: 18.4%
Preparing: 23.0%
Preparing: 100%
Restarting...
System going down for install...
Blessing i386 macOS System on /..
Submitting log to https://jamfinstance.com/

[devlinford]

Hi all...

I'm seeing issues with startosinstall as well...it appears more specifically withe 'nohup' command though. Is anyone one else seeing this issue on output:

nohup: can't detach from console: No such file or directory

@kc9wwh can you shed some light on what the 'nohup' and 'eval' commands are doing? and/or how I can use a different command to call the starttoinstall?

[LuxCalamitatis]

Seeing the same problem occuring randomly. Happened while upgrading from 10.13.6 to 10.14.x - The process sometimes gets stuck in the full screen dialog on physical machines.

[mpermann]

I too am seeing issues with upgrades getting stuck on the full screen Preparation phase when moving from macOS 10.13.6 to 10.14.3. I just started deploying the workflow to my beta tester folks today and I've had 9 out of 16 get to the preparation phase and not move beyond that. These folks are all admins with FileVault enabled and fully encrypted. @kc9wwh I'm wondering if you've seen anything like this in your usage of the workflow? In all of my testing with my tester systems I've not run into this issue. But all of my testers were tested with fresh macOS 10.13.6 installs using the workflow to complete the upgrade. All of my beta testers are production systems with most having at least one in place macOS upgrade to 10.13.6. The newest systems that I deployed last fall that started on 10.13.6 so far have all upgraded to 10.14.3 without issue. It seems like most of my issues have been on systems that started with macOS 10.12.x or older.

[mpermann]

I've been fighting this issue with the startosinstall command not starting on some of my beta tester computers. What I found was where I had failures, the computer had at least one in-place OS upgrade done using this workflow with a previous version of the script (vers. 2.6.1). It seems like that workflow was leaving around a /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist file that points to the High Sierra installer that we deployed last year. I noticed in the system.log file the following errors: Mar 6 08:14:49 Delete-Test-55675 com.apple.xpc.launchd[1] (com.apple.install.osinstallersetupd[2692]): Could not find and/or execute program specified by service: 2: No such file or directory: /Applications/Install macOS High Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd Mar 6 08:14:49 Delete-Test-55675 com.apple.xpc.launchd[1] (com.apple.install.osinstallersetupd[2692]): Service setup event to handle failure and will not launch until it fires. I'm wondering if others may be seeing the same issue or not. I setup an EA to check for the existence of that file and I'm finding it on a lot of my production systems that would have run the workflow last year. The Mojave workflow I am testing is using the 2.7.2.2 version of the script this year and it's creating that same Launch Agents file but I'm guessing that since the old Launch Agent is still there and loaded it is causing the issue. I'm curious what others might be seeing.

[joe-beserk]

FWIW, I saw the osinstallersetupd process never starting on the systems where the install would not kick off after staratosinstall was called. Eventually that lead me to the launchd item calling the osinstallersetupd process. Once I removed the launchd item, things ran ok consistently. On the test systems they only required password when the upgrade was finished to do the final reboot, but I suspect that may be because they have had the firmware on them upgraded already.

[kenchan0130]

Do you know if this issue matches https://github.com/kc9wwh/macOSUpgrade/issues/92? I don't familiar with this issue.

[neilmartin83]

I'm seeing the same issue here - cobbled this together to check for the LaunchAgent then unload and delete it - running this in the policy before the upgrade script works:

#!/bin/bash

if [[ -e "/Library/LaunchAgents/com.apple.install.osinstallersetupd.plist" ]]; then
    /bin/echo "LaunchAgent detected, checking for logged in user..."
    loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )
    if [[ "$loggedInUser" != "" ]]; then
        /bin/echo "User $loggedInUser is logged in, unloading LaunchAgent..."
        sudo -u "$loggedInUser" /bin/launchctl unload /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
    fi
    /bin/echo "Deleting LaunchAgent..."
    /bin/rm -rf "/Library/LaunchAgents/com.apple.install.osinstallersetupd.plist"
else
    /bin/echo "LaunchAgent not present, exiting..."
    exit 0
fi

[kenchan0130]

@neilmartin83 Thank you for your report. When you run the script, is this issue solved?

[neilmartin83]

@kenchan0130 apologies for the delay in replying, yes it’s been fine since I started running that script before the upgrade.

[Arrognz]

Hello everyone,

I'm really new to Mac OS Admin, and I had great hopes that startosinstall would make it easy for me to update my Mac remotely from 10.14.3 Mojave to 10.15.2 Catalina. However, I seem to encounter the same issue as @krispayne and @beneb12 :/

I systematically run into

2020-01-15 10:34:48+00 mini-2 startosinstall[1619]: OSInstallerSetup build: 1
2020-01-15 10:34:48+00 mini-2 startosinstall[1619]: No compatibility bundle on this version of macOS. Will assume compatible.

Any news regarding this issues ? What can I do to troubleshoot this ? I'm not using Jamf or any other Parc management tool.

I've tried redownloading the Install MacOS app from apple servers to make sure I was up to date on any provisioning certificate to no avail. I've tried going from my 10.14.3 to 10.15.2 but I also tried re-installing 10.14.3 using startosinstall. Both attempts resulted in the same error in install.log. There doesn't seem to be any security update available for my Mac. I've rebooted my machine multiple times.

Also, if my Mac does not have an access to the internet during the run of startosinstall, is it a problem ?

[bgrande12]

@ganzf FWIW, I've found success in removing eval from the installer command. Using 10.15.1 installer. It looks like this:

"$OSInstaller"/Contents/Resources/startosinstall --agreetolicense --forcequitapps --pidtosignal "$jamfHelperPID" >> $osinstallLogfile 2>&1 &

[milkerson]

Hello everyone,

I'm really new to Mac OS Admin, and I had great hopes that startosinstall would make it easy for me to update my Mac remotely from 10.14.3 Mojave to 10.15.2 Catalina. However, I seem to encounter the same issue as @krispayne and @beneb12 :/

I systematically run into

2020-01-15 10:34:48+00 mini-2 startosinstall[1619]: OSInstallerSetup build: 1
2020-01-15 10:34:48+00 mini-2 startosinstall[1619]: No compatibility bundle on this version of macOS. Will assume compatible.

Any news regarding this issues ? What can I do to troubleshoot this ? I'm not using Jamf or any other Parc management tool.

I've tried redownloading the Install MacOS app from apple servers to make sure I was up to date on any provisioning certificate to no avail. I've tried going from my 10.14.3 to 10.15.2 but I also tried re-installing 10.14.3 using startosinstall. Both attempts resulted in the same error in install.log. There doesn't seem to be any security update available for my Mac. I've rebooted my machine multiple times.

Also, if my Mac does not have an access to the internet during the run of startosinstall, is it a problem ?

We're also seeing this, although using a different script, (https://github.com/bp88/JSS-Scripts/blob/master/OS_Upgrade.sh)... We would routinely have this issue when we used this script for our Mojave upgrades. Never knew why.

I'm actively testing whether outstanding software updates or the launchdaemon will resolve this...

[fponcelin]

Hi everyone,

Somewhat related problem I faced, and how I solved it: I've been experimenting with this script, in combination with this one (replacing the software update code with a Jamf policy trigger calling macOSUpgrade).

What I experienced was that when macOSUpgrade would execute, everything would appear to work fine, except the full screen jamfHelper and startosinstall would suddenly terminate almost immediately after starting, with no error or crash log of any kind. When looking at the system logs, I would see startosintall followed by osinstallersetupd starting to do their thing as expected, but then suddenly stopping. I tried to see what the system was doing, tracking each PID and trying to identify what killed these processes using DTrace, only to find that launchd sent the terminate signal seemingly out of nowhere.

After some research on the inner workings of the system, my gut feeling was that because both jamfHelper and startosinstall are executed in the background (with the & at the end of their line), they therefore become children processes of macOSUpgrade. Then macOSUpgrade terminates (almost immediately after, without waiting for its children to finish) and as a result the system terminates all children processes, stopping the installer in its tracks and dismissing the jamfHelper window.

A solution I found, inspired by this discussion, was to add this line before calling jamfHelper and startosinstall: set -m Doing this made jamfHelper and startosinstall completely independent from the macOSUpgrade PID, and solved my issue!

I don't know know if it's a good solution (I'm still quite new to Jamf and sysAdmin in general), but it appears to work just fine.

Hope this helps...

[macadmincat]

Hey @fponcelin, I'm running into the same problem and have been trying to resolve all weekend. Can you share where you added the set -m in the script. I would like to test the same and see if I get the same results. Thanks!

[fponcelin]

@macadmincat I added it right at the start of the # APPLICATION section, just before ## Launch jamfHelper. I also added set +m at the very end of the script (before exit 0), although that might not be needed (I don't know for sure '^_^).

[macadmincat]

@fponcelin You nailed it! I updated the script as you suggested and ran through several upgrades to both Mojave and Catalina. The upgrade process works perfectly with no issues hanging up. Thanks for your assistance!!!

[crystalllized]

I was also having this problem as recently as this week, I added set -m as recommended by @fponcelin and the issue seems to have resolved!

[Hambeard]

I can also confirm that the solution suggested by @fponcelin works.