Upgrade kext not listed real latest version for some kext

[maverx72]

When I checked Broadcom kext https://github.com/acidanthera/BrcmPatchRAM this site appears the latest version is 2.6.3 but OCAT kext update process shows me the latest version is 2.6.2. Thanks for the amazing OCAT app.

[maverx72]

Same for voodoops2

[ic005k]

When you click on the "Check for Kexts updates" button, please wait for it to finish. It will then refresh the current Kexts version, and you should see the latest version number at this time.

[ic005k]

For the DEV version, there may be some problems due to some naming inconsistencies. For example.

"VoodooPS2": { "type": "Kext", "versions": [ { "commit": { "message": "Bump version", "sha": "4d8fd019b01d276e8c6acbcbb1e7c36d0890fcb1", "tree_url": "https://github.com/acidanthera/VoodooPS2/tree/4d8fd019b01d276e8c6acbcbb1e7c36d0890fcb1", "url": "https://github.com/acidanthera/VoodooPS2/commit/4d8fd019b01d276e8c6acbcbb1e7c36d0890fcb1" }, "date_authored": "2022-08-06T14:09:45+00:00", "date_built": "2022-08-06T14:15:21.868299+00:00", "date_committed": "2022-08-06T14:09:45+00:00", "hashes": { "debug": { "sha256": "8e4b96881c76beb621f522767df0a578fbebec6f103aaf46cbb075c0b1671148" }, "release": { "sha256": "7c49bb4a17226294a5684dbcc98ff51ef388f4d6ffeda2da2c703f2dd89e326f" } }, "links": { "debug": "https://github.com/dortania/build-repo/releases/download/VoodooPS2-4d8fd01/**VoodooPS2Controller**-2.3.0-DEBUG.zip", "release": "https://github.com/dortania/build-repo/releases/download/VoodooPS2-4d8fd01/**VoodooPS2Controller**-2.3.0-RELEASE.zip" },

The details can be seen here: https://raw.githubusercontent.com/dortania/build-repo/builds/config.json

[ic005k]

For the DEV version, OCAT does not exclude special handling of these exceptions in the subsequent upgrade process, thanks for the feedback.

[ic005k]

The latest version of OCAT has solved this problem, please update it.

[maverx72]

Yes its solved quick respond thanks.

[chriswayg]

The latest version of OCAT has solved this problem, please update it.

@ic005k I still have the issue on V20220232. For me it is currently impossible to update kexts using OCAuxiliaryTools, as the Check for Kexts Updates button does not function as it did previously.

When switching to the Dev version of the kexts, everything actually seems to work as expected, as the GUI shows an update-check and apparent download for each individual kext indicated by a moving blue progress bar on top. But when switching back to the Stable versions, the progress from Check for Kexts Updates seems to stop after attempting the first kext. No progress at all, and it appears as if it fails internally.

This is the screenshot after Check for Kexts Updates :

For comparison, Hackintool showed the correct upgradable kexts:

[ic005k]

@chriswayg I have recorded and will troubleshoot later, thanks for the feedback.

[chriswayg]

I just upgraded another system from OC 0.8.2 to 0.8.4. and it had the same issue. I could not update the kexts unless I switch to the DEV version. - Thus my current workaround is to update to the dev versions of the kexts with OCAuxiliaryTools, while using the stable version of OC.

[ic005k]

@chriswayg The reason for this problem seems to be a GitHub issue? When you visit https://github.com/acidanthera/Lilu/releases anonymously, you'll find that you can't access the latest release properly (it's always loading...) I don't know what the reason is at the moment.

[chriswayg]

@chriswayg The reason for this problem seems to be a GitHub issue? When you visit https://github.com/acidanthera/Lilu/releases anonymously, you'll find that you can't access the latest release properly (it's always loading...)

@ic005k, I checked it in Firefox, and it does load for me without logging into Github including the ability to download the release file. Maybe an intermittent problem, or some weird DNS or routing issue?

Inside the app the issue looks like its remaining, but its hard to be certain without checking it in a fresh VM, as it seems to be now stuck on the DEV versions, not reverting to the Lilu 1.6.2 stable release from the currently shown 1.6.3 dev version.

Could you at just show an error in the GUI, when it is unable to fetch the files from Github?

Currently there is no indication that something is wrong, and I would have just thought that there was new version without checking at the acidanthera repo.

[ic005k]

@chriswayg Glad to see your feedback, in fact some other Kexts can check for updates properly, such as VirtualSMC.kext etc. I will continue to analyze and try to provide a solution. If you have any other clues or ideas, please feel free to leave a comment.

[ic005k]

Could you at just show an error in the GUI, when it is unable to fetch the files from Github?

I will consider it. For now, the act of checking for updates is automatically interrupted if the file is not fetched properly from GitHub.

[ic005k]

@chriswayg Also, this can be a bit of a headache.

[chriswayg]

Could you at just show an error in the GUI, when it is unable to fetch the files from Github?

I will consider it. For now, the act of checking for updates is automatically interrupted if the file is not fetched properly from GitHub.

Maybe a more subtle and less intrusive way than an error would be a change of color to red for the version number shown in the Available column when updating a kext from Github is unsuccessful. At least there would be a clue to the user, that the latest stable version may not have been fetched from the Github server.

I tried this with a fresh install of OCAuxiliaryTools in a macOS VM I use for development and noticed a few additional reproducible quirks when trying to update the kexts, but the Github server fails for some reason. I will try to explain these quirks below.

First attempt I select each kext one-by-one (not select all!) and press the "Check Kexts for Updates" button each time.

Out of 6 kexts, 3 version updates were shown correctly and 3 were displayed incorrectly:

I then tried the same with the DEV chexkbox selected and everything worked correctly:

Then I tried to revert each kext to the stable version one-by-one, but the three unreachable kexts (Lilu, Whatevergreen & AppleALC) failed to revert to the stable version:

Each time there was no clue given to the user that anything had gone wrong.

An additional quirk is when selecting all 6 kexts, the update attempt will stop after the first failed kext. Thus it will attempt Lilu and then not even try VirtualSMC which would have worked correctly. This is a related, but separate bug, as IMHO there is no good reason for the process to fail silently after the first kext fails to update from Github. This affects the initial update attempt as well as the attempt to revert to the stable versions.

My expectation (for the current example) would be that if I select all 6 kexts, and I click the "Check Kexts for Updates" button, the following would happen:

1. It would correctly update the "Available Version" for each kext that has a reachable Github server
2. In case of an unreachable Github server, it would mark each "Available Version" with possibly a red color version number
3. It would continue to try the next kext, until it has covered all the selected kexts, either updating the version number or marking it red upon failure

I did test this with more than 6 kexts, but its easier to explain, if I limit my example to a small number. Quite a few additional kexts do not get updated consistently and for the user the result is currently so unpredictable, that it either requires manually checking https://dortania.github.io/builds/ for each kext's current stable version or checking with another tool such as Hackintool. (I just gave up and updated to the DEV versions of all kexts, as that still works fine.)

This issue cannot really be caused by a failure of the Github server (neither could it be connectivity issues), as the same failed kexts can be viewed, accessed and downloaded from each Github repo without a problem, either manually using the website or semi-automatically using Hackintool.

There must be something peculiar in the way that OCAuxiliaryTools is trying to access Github. - Are there any logfiles from OCAuxiliaryTools that would help analyze the cause?

[ic005k]

@chriswayg The reason for this problem seems to be that the source code of the web page no longer contains the download address of the distribution file, for example, for Lilu, which has the following source code.

view-source:https://github.com/acidanthera/Lilu/releases

[ic005k]

@chriswayg This could be some of the recent changes GitHub has made. If this is the case, then OCAT will have to find another way. The source code of the page no longer contains the download address of the distribution, which means we can't crawl the source code of the page to get the download link of the file, which seems a bit frustrating.

[ic005k]

@chriswayg The problem has been solved, please upgrade to the latest version.

[chriswayg]

@chriswayg The problem has been solved, please upgrade to the latest version.

Great, it works! - I updated Screenshots and Kext Update instructions in the documentation accordingly:

https://chriswayg.gitbook.io/opencore-visual-beginners-guide/step-by-step/oc-auxiliary-tools-upgrade#upgrading-kexts

[ic005k]

@chriswayg Okay, also for more information about GitHub API access restrictions see.

"For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the person making requests."

https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting

[chriswayg]

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the person making requests.

@ic005k I never actually hit this limit with normal usage. I tried, and I have to click the update kexts button about 10 times in a row to go over that limit. So for most users it would not be a concern. Just the error message is not very helpful, if the user is not aware of the cause:

[ic005k]

@chriswayg These information prompts have been improved in the latest version.