[BUG] v32.0 - Install macOS Sonoma.app is downlaoded, but upgrade never happens, no switfDialog, nothing else happens. #476
Comments
|
Hi there, you have not specified the --reinstall flag so the script has done all you ask of it. Additionally, there is no such flag as --OS. Try --os. If you do intend to use --rebootdelay, ensure that you specify a value, e.g. --rebootdelay 300. --move is an obsolete flag except in very specific circumstances of which yours is not one. |
grahampugh
added
invalid
|
Hi Graham, Thank you for looking into my issue. I am not sure how I missed the "--OS" vs "--os" part, but I will fix it. Regarding the "reboot delay", the documentation doesn't clearly state that we have to specify a number with it, thank you for that information. Regarding the "--move" command, I was under the impression that unless I use this command, the downloaded "Install macOS *.app" would not be moved/located in the /Applications folder. Is this not true? Do I not need to use this? Regarding the "--reinstall" flag, I guess I misunderstood the documentation. I can use this command to install the new macOS (upgrade) ? I thought it would only reinstall the same OS version already installed? What do you recommend as my command parameters to use for doing an upgrade to macOS 14 without wiping the system? If I want to push my own installer ahead of time, I can use this script the way I did to first download it, and use a different policy later with the "-reinstall" command to notify the user to upgrade? Alternatively, I can push the InstallAssistant Package manually through Jamf, and then use the script to just do the upgrade? Thank you and sorry for all of the confusion and marking my mistakes as a bug. Sincerely, Aryo |
|
Ok I made the changes and seem to have gotten it to show up, asking for credentials, and then saying preparing the upgrade. Is it possible to not have the preparing screen show "OK" button? that way the screen can stay and keep the user informed of the progress? If there is documentation on this and I missed, I apologize.
Thank you |
|
One more thing, there seems to be a longer delay for the reboot delay than what is specified/shown to the user. Is this normal? I had a 180 seconds wait, once the countdown finished to 1 second, the computer waited another 30-60 seconds with the 1 second remaining screen still on, before it automatically rebooted. I just want to make sure this is expected behavior?
|
Thanks, yes that could be clearer. I will amend the wiki.
Not since we implemented Mist, which downloads direct to /Applications.
The --reinstall flag is documented here. I think it's pretty clear that it's used for reinstalling (that includes upgrading, but can be the same OS as currently installed) without wiping the drive: https://github.com/grahampugh/erase-install/wiki/4.-Upgrading-or-reinstalling-macOS-without-wiping-the-system
The only required parameters are:
All the other parameters are optional.
Yes
Also yes. |
|
Thank you for all of your help. I do think I might have found an actual bug. The way I was doing it earlier, not specifying --erase or --reinstall, which lead me to my initial issue, seems to leave the zsh running without an exit. I tried it 5 times, as part of my troubleshooting and eventually noticed the zsh doesn't exit properly and keeps running. This might explain why the Self Service button never marks "done" and keeps spinning as well?
I hope what I said makes sense? |
|
I cannot reproduce that. I just ran a policy that does |
|
I am using the launcher script, to run after the pkg installs, within the same policy? Did you use this method? I just do self-service availability for users to run manually. If you can't reproduce it, then it might be a one-off issue with that device I was testing on. |
|
I suggest trying without the launcher script to rule out an issue there. |
|
Closing through inactivity. |
Describe the bug
Using version 32.0, macOS 13.6.3 Apple Silicon, going up to macOS 14.2.1 as an in-place upgrade. We install the package and use the Erase-Install-Launcher script to call the erase-install.sh script all using the same Jamf Policy.
Jamf Policy Setup
Package (we donwloaded from GitHub, uploaded to Jamf, added to policy) runs first, then "after" the package is installed, it calls for "Erase-Install-Launcher script" with parameters in the Jamf Pro Script section.
Command parameters: --move --overwrite --OS 14 --min-drive-space 55 --check-power --power-wait-limit 300 --cleanup-after-use
The installer app is found, downloaded, moved to applications folder, then the script exits with code 0. The actual upgrade process never happens, user is not prompted for credentials, startosisntall never happens.
Also, the policy, which is called from Self Service, never stops spinning, never completes from Self Service, but the log is sent back to Jamf.
To Reproduce
Jamf Pro Policy, installs the pkg we downloaded from GitHub, then uses Launcher script with specific parameters from 4-10, to run the upgrade.
Parameters: --move --overwrite --OS 14 --min-drive-space 55 --check-power --power-wait-limit 300 --cleanup-after-use
Also used --rebootdelay in testing, no luck with that either.
Expected behavior
I imagine after the installer is downloaded, and moved to the Applications folder, it would be called and user would be prompted for password, switfDialog would open and we would see progress towards the actual upgrade, but non of that is happening.
Code/log output
Please supply the full command used, and if applicable, add full output from Terminal or from
/var/log/erase-install.log. Don't post a partial log - I need the whole thing. Either upload the log as a file, or paste the output in a code block like this:Screenshots
Environment (please complete the following information):
Additional context
Behavior seems to be the same on different Apple Silicon devices tested.
The text was updated successfully, but these errors were encountered: