ERROR: softwareupdate error: 100

[as...@siprep.org]

I have two stubborn machines that keep throwing this error. I've Googled the error, and apparently it's supposed to go away on its own or after a reboot, but these two machines (one iMac, one Mac Pro) keep throwing the error (it's been weeks now) after multiple reboots.

I've even tried on both machines completely removing Munki (including settings) and then reinstalling, to no avail.

I will say another odd thing about this situation—on these two machines, if I launch up Managed Software Center, I can't manually check for updates by clicking on Check Again. The button just does nothing. On any other machine, if I click Check Again, it will manually invoke a Munki update. This happens regardless of which user I'm logged in as... and only on those two machines!

These two machines are complete outliers (the iMac is the exact same image as 19 other machines, and the other 19 have no issues with Munki, and the Mac Pro is the exact same image as 9 other machines, and the other 9 have no issues with Munki).

This is the relevant output from sudo managedsoftwareupdate -vvv:

Checking Apple Software Update catalog...

    Caching CatalogURL https://swscan.apple.com/content/catalogs/others/index-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog

    Options: {'logging_function': <function display_debug2 at 0x10c7e1c80>, 'additional_headers': {u'User-Agent': u'managedsoftwareupdate/2.2.4.2431 Darwin/14.4.0 (x86_64) (iMac12,1)'}, 'file': '/tmp/munki_swupd_cache/mirror/apple.sucatalog.download', 'cache_data': {

    etag = "\"4877b8-51b691b793e80\"";

    "last-modified" = "Tue, 21 Jul 2015 21:12:10 GMT";

}, 'url': 'https://swscan.apple.com/content/catalogs/others/index-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog', 'follow_redirects': True, 'download_only_if_changed': True, 'can_resume': True}

    connection_willSendRequestForAuthenticationChallenge_

    Authentication challenge for Host: swscan.apple.com Realm: None AuthMethod: NSURLAuthenticationMethodServerTrust

    Allowing OS to handle authentication request

    Status: 304

    Headers: {u'Expires': u'Wed, 22 Jul 2015 20:01:37 GMT', u'Keep-Alive': u'timeout=15, max=272', u'Server': u'Apache', u'Connection': u'Keep-Alive', u'Etag': u'"4877b8-51b691b793e80"', u'Cache-Control': u'max-age=14400', u'Date': u'Wed, 22 Jul 2015 16:01:37 GMT'}

    Item is unchanged on the server.

    /tmp/munki_swupd_cache/mirror/apple.sucatalog already exists and is up-to-date.

Checking for available Apple Software Updates...

    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '-v', '-l', '-f', '/tmp/munki_swupd_cache/ApplicableUpdates.plist']

ERROR: softwareupdate error: 100

Finishing...

Done.

Any ideas?

[Nick McSpadden]

This has been discussed a number of times on munki-dev (check the archives), but the result is pretty much always the same: nobody has a solution, and it goes away on its own eventually.

I've never even been able to come up with a useful reproduction or explanation of behavior that triggers it.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Nick McSpadden
nmcsp...@gmail.com

[as...@siprep.org]

Thanks, Nick. I guess it's good to know I'm not alone, then :)

I'll just see if it goes away on its own after a while. Thanks again.

[Erik Gomez]

Reboot the machines. 

Sent from my iPhone

[as...@siprep.org]

Have already. Didn't help. Yeah, I'd read one of Greg Neagle's old posts that said it will go away eventually but rebooting can speed along that process. It hasn't worked for these two machines, but I'll keep trying!

[Bradley Herdson]

I know this is an old post but I too encountered this issue today. I'm posting my resolution in the hopes that it will help someone in the future who searches for help with this issue:

Problem: When attempting to install Apple Updates from Reposado server MSC returns the error "An error has occurred. The operation couldn't be completed. (NSURLErrorDomain error -1100.). In Terminal using "managedsoftwareupdate -vvv" the returned error was: ERROR: softwareupdate error: 100 

Scenario: 10.11.2 Machine, using CatalogURL in /Library/Preferences/com.apple.SoftwareUpdate.plist to define reposado SUS.

Findings: The "LocalCatalogURLBase" string in the reposado preferences.plist file did not EXACTLY match the reposado SUS web address. In this case the port values were left off. Once a repo_sync had been run the sucatalog package path references were incorrect.

Solution: 

1. Update reposado preferences.plist "LocalCatalogURLBase" to correct value. 

2. Delete sucatalogs in use (i.e: /content/catalogs/others/index-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1_production, etc..).

3. Re-run repo_sync utility to generate sucatalogs with corrected address.

This may not solve your problem, but this is the first thing I recommend you check if you receive the softwareupdate  error: 100 message.

Any feedback to tighten this post is welcomed.

[Nicolas Zimmermann]

Adding my two cents.

Saw this a few months back on some of my clients only after switching them to a test repo.

Checked for softwareupdated events in a faulty client's /var/log/install.log and found a 404, like such:

softwareupdated[304]: SoftwareUpdate: Error encountered in scan: Error Domain=NSURLErrorDomain Code=-1100 "The operation couldn’t be completed. (NSURLErrorDomain error -1100.)" UserInfo=0x7fde01e87e20 {PKURLErrorResponseHeaders=<CFBasicHash 0x7fde01e2d770 [0x7fff7c7c6ed0]>{type = immutable dict, count = 5,

        entries =>

                0 : Server = Apache

                3 : Content-Type = <CFString 0x7fddf8b11680 [0x7fff7c7c6ed0]>{contents = "text/html; charset=iso-8859-1"}

                4 : Content-Length = 478

                5 : Connection = <CFString 0x7fddf8b163a0 [0x7fff7c7c6ed0]>{contents = "keep-alive"}

                6 : Date = <CFString 0x7fddf8b8d7b0 [0x7fff7c7c6ed0]>{contents = "Thu, 24 Sep 2015 15:11:38 GMT"}

        }

        , PKURLErrorStatusCode=404, NSErrorFailingURLStringKey=http://swcdn.apple.com/content/downloads/16/16/031-34571/e2klecbgutn97745ye8a8tw75dudlpw66e/031-34571.English.dist}

In my case the link was 404 because this repo was not caching updates locally, and thus would be serving updates that might have be deprecated by Apple since the previous sync. The fix in this case was to repo_sync again, effectively culling dead links in the catalogs.

For reference, this was a gatekeeper update, several of which happened over a few weeks IIRC ; seeing as that repo didn't sync daily, the errors reoccured a few times, always traced to the same root cause and fixed in the same fashion.