-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
startosinstall sometimes does not run #44
Comments
@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. |
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] Any ideas @kc9wwh ? |
@Genesis2kx Can you get a hold of the /var/log/install.log from that machine? |
@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? 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. |
@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. |
@Hacksore - Do you see the 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...
|
@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. |
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
|
I am seeing this issue as well with a forked/modified copy of your script. I am now going back to your original (2.6.1) to see if it is something I have changed. |
I've encountered this issue yesterday when going from 10.13.6 to 10.14.1 |
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:
Typically, we try again via Self Service and if it works, yay! if not, then we run the policy via 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. |
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 |
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. |
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:
Unfortunately, I didn't think to do an 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:
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 |
@sdpalmer we can't monitor for that. The script is setup to exit before the upgrade actually completes otherwise the |
@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. |
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.
|
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? |
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. |
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. |
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 |
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. |
Do you know if this issue matches #92? |
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:
|
@neilmartin83 |
@kenchan0130 apologies for the delay in replying, yes it’s been fine since I started running that script before the upgrade. |
Hello everyone, I'm really new to Mac OS Admin, and I had great hopes that I systematically run into
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. Also, if my Mac does not have an access to the internet during the run of |
@ganzf FWIW, I've found success in removing
|
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... |
Hi everyone, Somewhat related problem I faced, and how I solved it: What I experienced was that when After some research on the inner workings of the system, my gut feeling was that because both A solution I found, inspired by this discussion, was to add this line before calling 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... |
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! |
@macadmincat I added it right at the start of the |
@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!!! |
I was also having this problem as recently as this week, I added |
I can also confirm that the solution suggested by @fponcelin works. |
Added set -m to enable job control for the Application section of the script. The solution for this fix was proposed by fponcelin in kc9wwh#44 (comment) Reference for set builtin command https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
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?
The text was updated successfully, but these errors were encountered: