I've been seeing the exact same error but I'm not specifically using cached packages. Where I'm seeing it is randomly when packages are downloaded from our http distribution point. Perhaps the same mechanism as cached packages are used for resumable downloads? I'm uncertain.
I know nothing is wrong with the package as vast majority of clients that grab it off the http DP successfully install it and there have been no errors with the package on our AFP DP.
We don't have https enabled and we are still seeing this.
One thought I'm curious about is when is a receipt left for a policy? Is it left only after a policy has successfully completed or could one be left on a policy that ran but didn't complete successfully?
Yes, I am seeing this too some of the time. (JSS 8.6.2) on (Virtualized OSX Server 10.6.8)
Mostly OK, but ever so often this occurs.
Sometimes it explainable - for instance some update being installed, and someone launches the program, before the update is complete, or someone logs in.
But on some other occasions, there is no apparent explanation.
eg: Package install to 6 machines, and one errors out, and the other 5 OK.
Fortunately it's been rare enough not to cause much of a problem.
On some occasions I think the problem may have been related to an I/O bandwidth issue
– for instance co-insiding in time with a large upload to the Casper distribution server
so I/O was restricted - so perhaps a time out issue ?
I am also running into this issue with 9.2 when trying to cache a very large file for distribution at a later point. I agree that it mainly has something to do with the network connection being interrupted (bandwidth, dropped packets, disconnect, etc) Has this every been fixed?
To be honest I haven't looked more into this as I'm pretty sure it has to do with the packages not fully being cached.
I tested this by caching of a package and then disconnected the computer so the package was only partially cached. I then ran a recon and sure enough that computer showed up in my Smart Group that looked for the cached package. So it would then receive the next policy that was to "install cached" and of course it failed.
I did submit a Feature Request to make this Smart Groups looking for Cached packages a little smarter and confirm the package was fully downloaded. Feel free to vote it up. Here is the link https://jamfnation.jamfsoftware.com/featureRequest.html?id=1293
are these non-flat pkg's being served from an HTTP or SMB distribution point?
if they are, I'd bet the package download isn't completing successfully, as you thought. Wrap those non-flat pkgs in a DMG and use the "install pkg from DMG" script from the resource kit to install them and you should avoid this problem.
That's what it was in MY environment, anyway! ymmv
Non-flat, yes. Being distributed over AFP though. Not sure if that makes a difference.?.
I've wrapped packages in DMGs before but it's been awhile so I don't remember the outcome. Certainly worth trying again. : )
its definitely worth testing. if you have the same issues with DMG's I'd start looking around for other things in your environment that could be interfering with the downloads.
