Mojave 10.13.4 issues

498 views
Skip to first unread message

Gregory Neagle

unread,
Jan 24, 2019, 3:22:35 PM1/24/19
to repo...@googlegroups.com
You may notice issues with the 10.13.4 update not showing as available on some machines if they are using a reposado server for Apple software updates.

Here's why:

(This looks like an sucatalog authoring error on Apple's part)

There are currently two "BridgeOSUpdateCustomer" updates offered:
041-31307       BridgeOSUpdateCustomer                             10.14.3    2019-01-22
041-31307::1    BridgeOSUpdateCustomer                             10.14.3    2019-01-22 

In the 10.13 sucatalog, product 041-31307 has paths starting with `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`

in the 10.14 sucatalog, product 041-31307 has paths starting with `content/downloads/28/02/041-31307/ix7l1mpxyd4mykuv8c7gamghohr74d2tks/`
                                     product 041-31307::1 has paths starting with `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`

repo_sync normally syncs the 10.13 sucatalog first, populating `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`
Then it syncs the 10.14 catalog, but notices it already synced product 041-31307, so it skips that.
It then syncs product 041-31307::1, possibly replacing some of the items it previously synced to `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/` when it did the 10.13 sucatalog sync.

So repo_sync doesn't do a complete sync of the two products, and clients running 10.14.x that need the BridgeOSUpdateCustomer may not be able to download the needed files. This results in a "Error 100" from softwareupdate. If you examine the log at /var/log/install.log you may see entries like this:

2019-01-22 17:16:57-06 foobar softwareupdated[777]: SUScan: Error encountered in scan: Error Domain=NSURLErrorDomain Code=-1100 "(null)" UserInfo={PKURLErrorResponseHeaders=<CFBasicHash 0x7fa4f8d9f040 [0x7fff9699e8f0]>{type = immutable dict, count = 5,
entries =>
0 : Date = <CFString 0x7fa4f3dc4a40 [0x7fff9699e8f0]>{contents = "Tue, 22 Jan 2019 23:16:48 GMT"}
3 : Content-Type = <CFString 0x7fa4f3d403f0 [0x7fff9699e8f0]>{contents = "text/html; charset=iso-8859-1"}
4 : Connection = close
5 : Content-Length = 377
6 : Server = <CFString 0x7fa4f3d1f050 [0x7fff9699e8f0]>{contents = "Apache/2.2.15 (Red Hat)"}
}

The workaround for now is to set (or modify) AppleCatalogURLs in reposado's preferences to ensure reposado syncs the 10.14 sucatalog _before_ the 10.13 sucatalog. For example:

<key>AppleCatalogURLs</key>
  <array>
  </array>


Only time will tell if this is intentional on Apple's part and if a more robust fix will have to be added to reposado's code.

Thank you to Eric Holtam and other members of the MacAdmins Slack for helping diagnose this issue.

-Greg


Gregory Neagle

unread,
Jan 24, 2019, 3:59:13 PM1/24/19
to repo...@googlegroups.com
And of course I mean Mojave 10.14.3. 

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "reposado" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reposado+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brinn Joyce

unread,
Jan 24, 2019, 6:06:52 PM1/24/19
to reposado
Cheers, I had noticed this yesterday and this explains why I wasn't able to reproduce it on my test server - I'm only replicating the 10.14 catalog on there.
Successfully ran with the workaround, so hopefully things will start updating now.

Christian Borchmann-Backhaus

unread,
Feb 5, 2019, 9:04:02 AM2/5/19
to reposado
Thank you Greg... This fixed my problem...
Reply all
Reply to author
Forward
0 new messages