3.0b3/2.0 w/macOS13 - Issue w/Super waiting for download but download never starts about super HOT 9 CLOSED

I have automatic downloads disabled, however the update did already download and prepare during a previous attempt by super. It seemed to keep stalling when trying to initiate that download that had already completed. I increased the timeout to over an hour but obviously that didn't make a difference, neither did a reboot.

If there is a way to detect a completed download that would help. However If there isn't a way to detect if the update was previously downloaded, are there any terminal commands that I could manually run that would flush/reset any updates already downloaded so the process can just start fresh?

from super.

This is not an issue with super. After the Jamf API command is sent, there is nothing super can do but wait for the download to start. We literally have no control over the download process after the MDM command workflow is started... none. Instead super waits for softwareupdated to start the download to complete, and quite often it simply will not. The update.log is the raw output of the softwareupdated process, and if it never starts to download then super v3.0 will properly timeout and try again. See this example log for what should happen when the download is working.

from super.

Reopening for clarification... are the affected systems set to automatically download updates? If so, that could be the cause. In other words, if the update is already downloaded before the MDM command tells it to download, then the softwareupdate log may not indicate any download progress because it's already done. If this is the case then there could be something super could do to try and detect if the update was previously downloaded automatically.

from super.

The problem is that there aren't any good methods to detect this. The only "official" method is to literally run softwareupdate --download every time super runs to validate previous downloads, but as we all now know... every run of softwareupdate is another chance for it to hang. Normally super keeps track of downloads it completes to avoid re-downloading, so did you reset super between download/install attempts?

from super.

Yes I did reset super between download/install attempts but it didn't have any effect.
I have a feeling this would be a rare occurrence. It's only come up this once, and super has been able to reset other times.
Maybe in the future a flag could be added to force a re-download of all updates but it's probably a low priority at this point.

from super.

It looks like someone submitted a pull request for what sounds like this same issue, I noticed you had commented on it a bit ago. Think that could be the solution?

from super.

It's not ideal as it still requires running softwareupdate again... an ideal solution would be to know before any download is attempted if the update is already cached. I found this... working on it... defaults read /System/Volumes/Update/Update.plist update-asset-attributes

from super.

Well.. I've tested some things... I will likely be re-architecting the download mechanism again... stay tuned for the next beta.

from super.

Please check out the super v3.0b4 as it has a completely rearchitected download workflow.

from super.