Skip to main content
Question

Installing Cached packages in Waiting Room Fails Sometimes

  • June 28, 2013
  • 9 replies
  • 67 views
K
Forum|alt.badge.img+12

I've seen this a lot over time and because it's not usually a large number of clients it fails on I haven't give it much attention. However, I've decided to look into it a bit more and am curious if anyone knows off hand what the exact issue is.

Here is what I'm doing.

  1. For large package deployments such as OS Combo Updates, I have a policy that "Caches" this pkg based on if the computer meets the requirements. This same policy also has the "Update Inventory" box checked so it runs a recon.

  2. I then have Smart Groups setup that have this cached pkg.

  3. I then have a second policy that is scoped to users in that Smart Group. This policy runs "every15", they receive a jamf helper message letting them know they have an update available and they have the option to install it now or delay it. Once they say it's ok to install, the policy is set to install the cached pkg.

The error I'm seeing is this

Installation failed. The installer reported: 2013-06-27 11:25:36.903 installer[79883:7b03] Package /Library/Application Support/JAMF/Waiting Room/NAMEOFPACKAGE.pkg uses a deprecated pre-10.2 format (or uses a newer format but is invalid).
installer: Package name is SU_TITLE
installer: Upgrading at base path /
installer: The upgrade failed (The Installer could not install the software because there was no software found to install.)

Is this happening because the cached pkg is not fully cached or is there some other issue I'm overlooking?

Thanks in advance for your help.

    9 replies

    A
    Forum|alt.badge.img+6
    • analog_kid
    • New Contributor
    • July 1, 2013

    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.

    K
    Forum|alt.badge.img+12
    • krichterjr
    • Author
    • Employee
    • July 2, 2013

    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?

    P
    Forum|alt.badge.img+9
    • PeterClarke
    • Contributor
    • July 6, 2013

    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 ?

    mojo21221
    Forum|alt.badge.img+12
    • mojo21221
    • Valued Contributor
    • November 7, 2013

    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?

    K
    Forum|alt.badge.img+12
    • krichterjr
    • Author
    • Employee
    • November 7, 2013

    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

    N
    Forum|alt.badge.img+19
    • nkalister
    • Contributor
    • November 7, 2013

    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

    K
    Forum|alt.badge.img+12
    • krichterjr
    • Author
    • Employee
    • November 8, 2013

    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. : )

    N
    Forum|alt.badge.img+19
    • nkalister
    • Contributor
    • November 8, 2013

    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.

    N
    Forum|alt.badge.img+19
    • nkalister
    • Contributor
    • November 8, 2013

    double post

    Terms & ConditionsCookie settingsAccessibility statement