Packages failing on install when syncing with 1.3.3+ #41
Comments
|
Oh that's unfortunate! “The package could not be verified” might be because you uploaded a package to the JCDS with Jamf Sync, which would update the checksum in Jamf Pro, but if you didn’t also update tobias, then it would fail with that error when it tries to get it from that DP. The "Certificate used to sign package is not trusted" could be that the upload or download was missing something so that the signature didn't match what is expected. Could you create a new Folder DP and synchronize the problematic files to that and then compare the sizes of those vs. the original working packages and see if there is a difference in the file sizes? If they are the same size, try going into terminal and do |
|
Hello, Same MD5 hash when making a new folder and syncing. I am not sure where the disconnect is, since like I said, 1.3.2 works great and never does this. When this first happened on 1.3.3, I also deleted the package from Jamf and re-synced the exact same package with 1.3.3, and it worked after that. When Jamf is trying to install the package from my DP, that is verifying it's the same hash as it has for the record, correct? When "Verifying package integrity..." is running? Next time I have a new package to upload, I will try with 1.4.0 and take a screen recording of everything, since by all logic, it should work without issue especially since it synced to my test folder. |
|
Regarding "Verifying package integrity...", when the same package is on multiple distribution points, there is only one package record in Jamf Pro. The jamf binary will download the file from the distribution point and then create the hash on the file that was downloaded and compare it with the hash that's stored in the package record. That way if a distribution point is somehow compromised, it won't install anything that it's not expecting. But if you have a different version of that package that was uploaded to one distribution point but not another, then it would refuse to install a package from the DP that wasn't updated. I'm not sure what the disconnect between 1.3.3 and 1.3.2 is either, however, we did change the process for uploading to a JCDS distribution point in order to be able to upload > 5GB files, so it's possible there is some edge case where it can fail. However, I would expect that when you synchronize a failed upload to a local folder, the size and for sure the MD5 should be different than the original. You could also try manually installing it too. If the MD5 is the same as the original and it manually installs fine but it cannot be installed by a policy, then that seems very odd. If the MD5 is different, I would need to know if the size is also different because that could potentially help pin down the problem. |
|
Hi Harry, I have a video ready showing my process of uploading with 1.4.0 and it failing to install from my DP, but installing from the Cloud, which I haven't seen before. It may have some identifying details on it, can I share it with you on an email or slack? I believe I see your user on Mac Admins. |
|
@joshnovotny sure...maybe just email me at harry dot strand at jamf dot com. Hopefully that bots aren't smart enough to figure that out. |
Hello,
Ever since updating to 1.3.3, packages sometimes do not get uploaded correctly, and end up failing while installing. Some package logs from Jamf:
Once I go back to 1.3.2, the packages upload and install without issue. I've been having to use 1.3.2 for daily use and then switch to 1.4.0 for larger files. This doesn't happen all the time either, just certain packages do this.
The text was updated successfully, but these errors were encountered: