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.
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"
I added a part at end to see if if the startosinstall fails and kills the jamfHelper window.
I noticed that was very helpful the handful of users that had an issue with the upgrade.
What do you think?
while [[ $(pgrep startosinstall) ]]; do # echo macos installer in progress sleep 3 done if [[ -d "/macOS Install Data/" ]]; then echo Ready for macOS install else # no instllall data echo macos Install Data Is not there, Preperation failed #kill the full screen window killall jamfHelper ## Remove Scripts /bin/rm -f /usr/local/jamfps/finishOSInstall.sh /bin/rm -f /Library/LaunchDaemons/com.jamfps.cleanupOSInstall.plist /bin/rm -f /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist /bin/echo "Launching jamfHelper Dialog (Preperation failed)..." /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -title "$title" -icon "$logo" -heading "Preperation failed" -description "We're sorry, we were unable to prepare your computer for $macOSname. Please restart and try again at a later time from Self Service. If you continue to experience this issue, please contact the Service Desk. Thank you." -iconSize 100 -button1 "OK" -defaultButton 1 -timeout 600 fi killall jamfHelper
@cubandave I actually didn't do that just because I let the
startosinstall binary handle the closing of
jamfHelper and want the script to actually complete prior to
startosinstall. In my testing, if
startosinstall finished and tried to reboot while the script was still running I would get multiple errors from Self Service. I haven't tested this recently, but thats what I used to get and as such just left it that way cause it continues to work great.
But if you need to modify it to make it work a certain way in your environment that is totally cool! Glad it is working for you 🙂
All Thank you all for you hard work on this. I seem to be struggling and being a newbie I am at a loss.
I have performed the following:
- Created two policies:
-- 1.) One to cache the Install macOS High Sierra.app in the /Applications folder - works successfully
-- 2.) The current self-service policy to install the OS using the script provided by Rosko from GitHub https://github.com/kc9wwh/macOSUpgrade
Issue: the Splash screen appears "Please wait as we prepare your computer for the macOS High Sierra..... This splash screen sat here overnight.
- Looking through the install.log from /var/log/install.log I do not see any errors or the startosinstall
- Looking through the JAMF.log it says "Executing Policy CPA-AllCampus-macOS High Sierra Upgrade
- In JAMF I receive the following:
What am I missing?
Thank you in advance!
There have been some issues around the
AssetCacheLocatorService, but we're not sure whats causing it. If you issue lines up, please try some of the suggestions their. If they work I'll add them into the script.
Thank you for getting back with me. I apologize for not getting back with you sooner.
I found the issue.
There was something wrong with the install macOS High Sierra.app. I could not even launch it manually. I created it on a VM using Extended Journal. So, this might had something to do with it. I grabbed another physical computer and built it from there. Seems to be working now.
I also had to hard code the User Variables in the script. As they were not working when inputting them into JAMF.
But hey, it is working now. Woo Hoo!
Hey all, I just started working on this and a bit confused. I dont see anything about how when you use the cache option it does not install the installer in the Applications folder. What do I need to do to get it from the hidden JSS folder to the Applications folder? Mind you it is a DMG. I am following these directions, although they are all fairly similar as I clicked on the links above.
@rkovelman you do not "cache" the installer in the traditional Jamf sense. Meaning, in the policy to cache the installer you do not choose "Cache" on the package. If you follow the instructions on the GitHub page, you use Composer to package up the installer, whether as a DMG or a PKG. If you install that PKG/DMG it does not run the OS installer, it simply places it where you want it.
So if you want the installer in /Applications, just install your DMG file. It will copy the OS installer into the folder and it will be there for the script to run against.
@stevewood i get what you're saying but I don't at the same time. As of right now the machines that need the upgrade have the 5GB installer in that hidden JAMF folder. Could I execute a script to open the DMG, and copy the contents of that into the Applications folder? Once that is done I can then have it delete the DMG file? I would think the whole point is to cache the file to the machine 1st, and then unpackage it. I dont see a way with the composer to have it install the file in the Applications folder.
@rkovelman First make sure the OS installer is in the main Applications folder where you want it to go, then in Composer, drag the installer into the sidebar (Sources) list. It will copy the installer in and create a new source, that you will likely want to rename, then build the package as a pkg or dmg file.
When the package gets deployed it will 'install' the installer into that location, but not run it. That's what the script is for.
Incidentally, you could install the installer in any location you want to, but would need to slightly modify the script to point to the correct location as well as using a different sed command to get the installer name. I'm doing that in my version of the script for this process. The main Applications folder is not a hard fast rule, just a suggestion and the script has some hardcoded stuff in it that expects it to be there. But it can be changed if you prefer.
@rkovelman the problem is you need to use "install" in the policy as the action for the package, not "cache". If you use cache then yes the package will just sit in that folder until something acts on it. Change it to install and when it runs it will place it in the Applications folder.
Edit: I think to add, where you're getting tripped up is that this isn't a real "cache" as in a Jamf caching process. Think of it like installing an app like Firefox or Google Chrome. You wouldn't (normally) set up a policy to cache that, then install it later, unless there was a specific reason for that. Usually you just tell the policy to install FF or Chrome and it lands in the Applications folder. This is the same thing, just that it's installing the Install macOS High Sierra.app. Folks here use the term 'cache' because it needs to be differentiated between running the actual app and "installing" High Sierra on the Mac. Make sense?
@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.
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.
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.
@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/*
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. ¯_(ツ)_/¯
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
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.
@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/system.log to see if there are any errors there pointing out to what happened.