Error 42: Logs show password is passed to startosinstall but the script times out? #424
Closed
chrisfromgh
started this conversation in
General
Replies: 6 comments
-
|
Check that you don't have some security software or restrictions in place that could prevent the installer app from running. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I am getting this same error whenever I am trying to erase a computer that was previously setup. Cortex was installed on the computer, but is disabled. I have not had this error before, but in the last two weeks or so, I have. I am using 29.2 version. I will try the latest version and see if that helps. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@grahampugh thanks for your tips on Slack here. I wanted to leave what I have been testing so far with others here in case anyone comes across this as well ( I will also add the --no-timeout flag with my future tests, thanks for that callout!) This is the command I have been running via a policy: /Library/Management/erase-install/erase-install.sh --reinstall --min-drive-space=25 --check-power --version=13.4.1 --no-fs --rebootdelay=180 --power-wait-limit=180 I tried testing this on a Ventura machine running 13.3 using version 30.1. The device was a fresh ventura install, enrolled, and ran dep notify. I then scope out Nudge and erase install to this machine. The test user is a standard user, I also grant the test standard user temp local admin (just to be sure its not admin related) The start os install times out still after 60 minutes. I was inspecting the /var/log/install.log file and saw these errors that stood out to me I will try doing some more research regarding these 3 errors that stand out to me: I have a suspicion its something we are doing to our fleet of devices... let's see how it goes |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Im having a similar issue where the installer on any Apple Silicone machines times out at 98 percent and stalls when trying to install 13.5.2. Was working previously on 13.5.1 so ill try that again. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I was having this issue, but then I tried v30.2 of the script. Sometimes I get a ? icon instead of the Ventura icon while preparing the installer but it does seem to work. Have been able to update 3 systems since changing to a newer version of the script. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
So I wanted to follow up with this and provide a conclusion at least to my issue. @grahampugh thanks again for your work on this script and just recently releasing ver 31. In the fear of the possibility of being called crazy 😅, I will just put it out there and say my issue was Nudge 🤷🏼♂️. Co worker of mine shared this with me: https://hcsonline.com/support/white-papers/how-to-upgrade-macos-using-erase-install-and-jamf-pro. It's an excellent write up from HCS and honestly not that far different from what we were doing in-house. Unlike our workflow though, we used Nudge, while HCS didn't. So what I did was I tried testing this multiple times on an M1 machine running Monterey 12.X. My tests consisted of having Nudge point to the update policy which was the erase install script, and then just letting it prompt the user via HCS method (without Nudge) In both methods, erase install was being run the same way by doing the following command: I will note that originally we were locking it down to a version instead of just letting the device update to the highest available update the way HCS was recommending. So every time I had Nudge prompt the user, and have it point to update policy which would eventually lead to the upgrading Mac OS screen, it would just never time out and never finish upgrading. I would wait overnight for the update to complete and nothing will happen. Just a bouncing back-and-forth progress bar that went indefinitely. Screenshot: On tests without Nudge and just letting the policy prompt with recurring check-in (as described in HCS pdf) the upgrade would run completely fine and give me an actual upgrade percentage (rather than the bouncing blue bar) and then it would finally restart. This was a successful test 3 times in a row (wiping and reinstalling Monterey and testing the upgrade) With Nudge it failed twice so I called it a day and decided to stop using Nudge as a prompting tool to point users to update. Screenshot: The only thing I can possibly think of is that Nudge under the hood is essentially SwiftUI, and Erase-install uses SwiftDialog, which is SwiftUI as well. Maybe there is a conflict there at runtime? It could be farfetched though and I am just making stuff up here. In any case, my team and I are moving forward with erase-install which is an awesome tool. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I have an issue with several machines in our fleet. It seems like its been a hit or miss with trying to get machines to update with this script.
Version of script: 30.1
Running script on: M1 Macbook Pro 2020 12.6.1
Deployment Method: Imported Script in Jamf ran via Self Service
Caching update before install: Yes
Here are the results from the logs:
The issue seems to revolve particularly around
Sending password to startosinstalland it just times out after 60 minutes and fails.Am I missing something? I manually imported the script into JAMF and am running it with the following flags so that users can run this from self service
And then I try restarting the device, and running the script again using self service, and for some reason then it works?
Also I use this other caching policy to cache the installer. Caching seems to work fine:
Our users typically have a
firstname.lastnameformat. Only mentioning if maybe that can be the issue?The fact that there is no information between these two inputs in the logs is just weird:
Could it be that the PID it references at the end for the timeout does not match the PID called here?:
At this point feels like I am pulling my hair out. This seems to particularly happen on Silicon macs? The user is not an admin btw, would this be the issue? I figure it shouldn't be because the user is a volume owner.
Have you experienced this issue?
Beta Was this translation helpful? Give feedback.
All reactions