Skip to main content

Hello,



I am trying to follow this guide from JAMF: https://www.evernote.com/shard/s398/sh/bec8a262-e33d-4ad9-80fa-05b939db6d8d/f4ca396a63caa510



I am using the script noted here: https://www.evernote.com/shard/s398/sh/bec8a262-e33d-4ad9-80fa-05b939db6d8d/f4ca396a63caa510/res/9163d1d7-3bbf-4e2f-b70a-0cd447c749a1/startosinstall.sh



I got everything else working so far (you do need another policy to place the .dmg in the applications folder that the article neglects to tell you). I would like the script to force the restart instead of being "soft". I tested it and found that any open application will stop the upgrade.



Just need it to forcibly and immediately preform the restart.



Thanks.



Here is the script:



#!/bin/bash
/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS Sierra.app" --volume $1 --rebootdelay 30 --nointeraction
killall "Self Service"

@rkovelman So, it sounds like you have some Macs that already have the DMG cached in the /Library/Application Support/JAMF/Waiting Room/ folder and are looking to convert that into a Install macOS High Sierra.app in the Applications folder. Is that right? If so, what I would do is build a Smart Group based on machines that have that DMG cached (use the Packages Cached by Casper/Jamf criteria option) and scope it to a policy that just does a "Install Cached" action on that same package, meaning in the policy Packages payload, add your DMG package there but change the option to Install Cached. Have that run on check-in, once per computer, scoped to the group mentioned before.
Once that runs on them, the High Sierra installer should then be in the main Applications folder, ready to run with the upgrade script.



Hope that helps.


@mm2270 Correct, I did that already, so we are good. When I run the script it tries to download the installer, which is should not need to do. It should see it is there and run it. I edited the script so it knew that, or thought it would.



Specify path to OS installer. Use Parameter 4 in the JSS, or specify here



Example: /Applications/Install macOS High Sierra.app



OSInstaller="$4"



OSInstaller="/Applications/Install macOS Sierra.app/"


@rkovelman it does check to see if the Installer is already present in the folder specified, here is lines 71-77 of the latest version:



##Specify path to OS installer. Use Parameter 4 in the JSS, or specify here
##Example: /Applications/Install macOS High Sierra.app
OSInstaller="$4"

##Version of OS. Use Parameter 5 in the JSS, or specify here.
##Example: 10.12.5
version="$5"


As long as the installer is present in the OSInstaller path and matches the target version specified below that, it will use that installer and not download a new copy. Ensure the target macOS version being deployed by the installer is used there and I also wanted to note that you don't need to escape the space in the OSInstaller variable, its handled by the script.


@rkovelman You do not need to escape the path since it is in quotes. Change this OSInstaller="/Applications/Install macOS Sierra.app/" to this OSInstaller="/Applications/Install macOS Sierra.app/" and try again.


Yeah, as @stevewood said, no backslashes in the path. Using them will cause it to not see the installer. That should probably get called out in the script, because it's not the most obvious thing that those aren't needed. I can see how someone not very experienced with scripting could get tripped up on that.


Thanks @Rosko . I had to edit the version to 10.12.6 and looks like all is good. Thanks to you, @mm2270 and @dan.snelson


Curious do you guys have it running updates after the policy runs? I have a policy that runs weekly for all Macs but curious if you run updates after the install? Is it within the same policy, or did you add to the script? Also, do you guys have it clear out cached folders or not?


@rkovelman No, I don't run anything after the upgrade; I'm just happy it worked.



I do run a script before to cause computers to submit updated inventory data: Deploying an OS X Upgrade: Recon at Reboot script.



The cache folders should be auto-cleared on successful execution, but I do have a maintenance script in Self Service users can run which executes:



/bin/rm -Rfv /Library/Application Support/JAMF/Waiting Room/*



… and …



/bin/rm -Rfv /Library/Application Support/JAMF/Downloads/*


@Rosko we've been using your script to upgrade users to 10.13.3, on our Jamf Buddy @dan.kubley's advice, and its been smooth sailing.



10.13.5 has only been out a couple months, and the script checks to make sure Install macOS High Sierra.app is at 10.13.3.



Is it too soon to ask...can we help test your script against 10.13.5, if so do you have an updated script, or should we tweak the minimum requirement in the script?



I'll post this to your Github page...I guess under "Issues" even though the only issue we have is that Mojave should have been Death Valley after the current High Sierra + APFS + Secure Token Administrator fiasco. ¯_(ツ)_/¯



Thanks,
Don




Hey @donmontalvo!



Hope your day is going well. The latest version of the script (v2.6.1) has been tested against 10.13.5 and I just did a test of the workflow last Friday without issue. The only thing you should have to change/update is line 77 (on the latest version) where we have:



##Version of OS. Use Parameter 5 in the JSS, or specify here.
##Example: 10.12.5
version="$5"


If you are not using the Jamf Pro Script Parameters, you can just update the hard-coded version we're looking for to 10.13.5.



Hope that helps! :)


Anyone using this script but not in self service on encrypted laptops? I need to do upgrades over night and I can't be in front of the computers as they are remote.



It all works when I sit in front of the machine to enter the passwords but no luck trying to bypass. I am going from 10.11.6 to 10.12.6


@TheDecline that would be a security hole, especially if you want to run it as the end user. I run it from SS, and on encrypted laptops, but leave it to the end user to do.


@rkovelman to an extent, Jamf has the "perform Filevault 2 authenticated restart" and is how I got then on 10.11. I was hoping someone is using the macOSupgrade.sh with that function some how.


@TheDecline if the machine is already encrypted there is no need to encrypt it again. Just install the OS and proceed.


Trying to go from 10.12.6 to 10.13.5 with a pre-downloaded High Sierra installer (run from a separate policy) and using the v2.6.1 of the @Rosko script. I am shooting for a non interactive method via policy to kick off the upgrade if possible.



I have the script configured to use the eraseinstall command, however when the upgrade policy runs it shows the "Please wait as we prepare your computer..." window then just never completes and throws me back to my existing Sierra desktop. I have read there are issues when trying to convert HFS (which is what my drives are) to APFS along with the macOS upgrade. Is this the reason it dumps out or am I missing something else? Attached is my Upgrade to High Sierra policy script config.


@kricotta - The --eraseInstall switch is only available on APFS volumes, hence the machine needs to already be on macOS High Sierra and have been converted to APFS.


@rkovelman Yes I know that. The issue is after the reboot it goes to file vault screen for authentication to proceed. Im trying to bypass that like it does when you manually update the OS.


@Rosko thanks, I turned off the option but still seem to be having issues. Basically when applied, it upgrades to High Sierra but doesn't do the APFS conversion at all. Is it possible to upgrade the file system to APFS in a different step or policy in Jamf and then following along behind that with the upgrade to High Sierra?


@kricotta if you are using the workflow here unmodified, then it should do the APFS conversion. If the upgrade is going through, but not the conversion and the script is the one mentioned, I would assume something is failing along the way and you'll want to dig into the /var/log/install.log and /var/log/system.log to see if there are any errors there pointing out to what happened.


@Rosko thanks very much for your help with this. I am starting back from scratch with the Sierra build and letting it go through the script to see what I can collect. I'll reply with what I find.


@Rosko I found something in my install.log that hints at an issue with the targeted drive. Basically I am half completing the script and it upgrades to High Sierra but never converts to APFS (and finishes wiping the drive etc). The same situation as this post:



https://www.jamf.com/jamf-nation/discussions/26978/unable-to-upgrade-macos



I should also mention that I am running a bootcamp partition as these lab computers have the option to dual-boot into Windows if chosen.


Is there a blog or wiki that explains how create a policy to use the script macOSUpgrade.sh created by @Rosko ?



I forgot if the Self Service policy should include a "Restart Options" or a restart by way of "Files and Process > Excute command". Or is the reboot already a function of



startosinstall


command?


@alex030cc What directory did you place your launch agent in? I have FV2 Encrypted Macs and am looking to get this going with @Rosko 's script.


@RLassus take a look at @Rosko 's Script shared on Github. He already implemented the LaunchAgent to his script. He uses the general "/Library/LaunchAgent/" path. But this will not matter. You can launch it from any path. However, use the provided script will be the easiest way.


Just a quick note to say that when installing 10.12.6 via script to startosinstall in older versions(up to10.12.3) it had the --volume entry in the script which if removed makes the script work with Sierra 10.12.6. i.e.
startosinstall --volume / --applicationpath
change to
startosinstall --applicationpath
Had me fooled for a while.