Skip to content
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.

Sign up for GitHub

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

Jump to bottom

xcode-cli-tools.sh failed with softwareupdate XPC error #61

Open
bacongravy opened this issue Mar 4, 2016 · 5 comments
Open

xcode-cli-tools.sh failed with softwareupdate XPC error #61

bacongravy opened this issue Mar 4, 2016 · 5 comments

Comments

@bacongravy
Copy link
Contributor

The xcode-cli-tools.sh script failed with the following output:

==> vmware-iso: Provisioning with shell script: ../scripts/xcode-cli-tools.sh
    vmware-iso: Mar  3 00:34:29  softwareupdate CLI[314] <Error>: /usr/sbin/softwareupdate: Service connection interrupted!
    vmware-iso: Mar  3 00:34:29  softwareupdate CLI[314] <Error>: /usr/sbin/softwareupdate: XPC error in __45-[SUCommandLineTool _refreshAvailableUpdates]_block_invoke (Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.softwareupdated" UserInfo={NSDebugDescription=connection to service named com.apple.softwareupdated})
    vmware-iso: Couldn’t communicate with a helper application.
    vmware-iso: : No such update
    vmware-iso: No updates are available.
    vmware-iso: Software Update Tool
    vmware-iso: Copyright 2002-2015 Apple Inc.
    vmware-iso:

I've only seen this happen once.

I'm using OSX_InstallESD_10.11.3_15D21.dmg, packer 0.9.0, and VMware 8.1.0 with the vmnet-natd patch.
@bacongravy
Copy link
Contributor Author

I wonder if this issue might have occurred because the VM is set to only use 2 GB of memory. I noticed that the boxcutter osx VM template recently bumped their memory configuration for El Capitan to 4 GB of memory, perhaps that would help here, too.

Would you be open to a pull request that makes the memory and cpus values into variables?

@mattieb
Copy link
Contributor

mattieb commented Mar 4, 2016

If you do find bumping the RAM solves this problem reliably, it may be worth doing. We did find that upping VRAM allowed us to go past 2048 MB on VirtualBox; until that time, it wasn't possible to (see #39.)

@tomcurran
Copy link

I'm seeing a similar error with both vmware and virtualbox

==> virtualbox-iso: Provisioning with shell script: ../scripts/system-update.sh
    virtualbox-iso: Downloading and installing system updates...
    virtualbox-iso: Dec 22 13:09:41  softwareupdate CLI[438] <Error>: /usr/sbin/softwareupdate: Service connection interrupted!
    virtualbox-iso: Dec 22 13:09:41  softwareupdate CLI[438] <Error>: /usr/sbin/softwareupdate: XPC error in __45-[SUCommandLineTool _refreshAvailableUpdates]_block_invoke (Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.softwareupdated" UserInfo={NSDebugDescription=connection to service named com.apple.softwareupdated})
    virtualbox-iso: Software Update Tool
    virtualbox-iso: Copyright 2002-2015 Apple Inc.
    virtualbox-iso:
    virtualbox-iso: Finding available software
==> virtualbox-iso: Provisioning with shell script: ../scripts/shrink.sh

@bacongravy
Copy link
Contributor Author

I found that adding a sleep 60 to the beginning of the script seemed to resolve this kind of unreliability with the softwareupdate tool for me. My suspicion is that sshd begins accepting connections before the OS is fully booted, and that the softwareupdate tool hangs or returns an error if some service it depends on hasn't been fully started yet. I spent some time trying to find something to block on (e.g. waiting for a specific process to be running) that would indicate when the system was really ready to be provisioned, but came up short. I also tried shorter sleep durations, but 60 seconds was the shortest duration I could find that seemed 100% reliable.

@tomcurran
Copy link

@bacongravy thanks. I didn't have success with 60 but did with 120. I'd advise using packer with -var provisioning_delay=120 based on my experience

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mattieb @tomcurran @bacongravy