[SCRIPT] PurgeWrangler: AMD + NVIDIA eGPUs for all Thunderbolt Macs
 
Notifications
Clear all

[Solved] [SCRIPT] PurgeWrangler: AMD + NVIDIA eGPUs for all Thunderbolt Macs  

 of  164
  RSS

techyowl
(@techyowl)
Eminent Member
Joined: 3 years ago
 

@fr34k
One way would be to monitor the activity log for new processes that spin up during a MacOS update from the App Store and see if some of them are common for every MacOS update and monitor the activity log for that. Another options would be to monitor the MacOS equivalent of syslog which I believe they just call it console log for the update messages. However this won’t work for major version changes as you cannot guarantee the end user will actually complete the update process. Might I recommend something more along the lines of an auto patch tool? The patch is essentially a sophisticated find and replace so if it doesn’t find it no harm done and another patch will hopefully come forward for that version onwards. I believe @Goalque used something similar in the automate-eGPU.sh script.

early-2015 13" MBP Retina + RX580@16Gbps-TB2 (AKiTiO Node via TB3->TB2 adapter)


itsage liked
ReplyQuote
fr34k
(@fr34k)
Reputable Member Moderator
Joined: 2 years ago
 

@techyowl
The problem there is that you would have a process running constantly, draining energy

Theoretically, the kexts should be consistent throughout the systems, so:
What do you think about: (we're clean atm)
sha the .kext and store result at save place
patch
sha the new one and append
--- next execution (maybe after update)
sha kext and reference check
a) match with clean install -> use procedure above
b) match with patch -> patch (if needed, maybe update breaks something)
c) no match at all -> execute repair function for that update to restore clean install -> patch

drawback: a repair function would be needed for every possible update scenario (e.g: .3->.4, .3->.5, .4->.5 etc.)

macOS-eGPU.sh on GitHub (fr34k's macOS-eGPU.sh on eGPU.io)
----
2016 15'' MacBook Pro + GTX1080Ti@32Gbps-TB3 (Sonnet Breakaway 550) + macOS 10.13.6 (17G65 driver: 378.10.10.10.30.107 + CUDA: 396.148)


ReplyQuote
punk.kaos
(@punk-kaos)
Active Member
Joined: 3 years ago
 
Posted by: goalque
Posted by: Michael Schmidt (URBN PXL)
Posted by: punk.kaos

Worked great on my 13in MBA with an RX560 after I patched my kexts for IOPCITunnelCompatible. Thanks a ton!

uhh any info about how you did that ... wanted to get a RX560 to run on my system so I can test it in FCPX

https://egpu.io/forums/mac-setup/app-automate-egpu-by-goalque/paged/2/#post-33291

Yeah, @goalque gave you better instructions than I was going to write. Follow that, its working great. Smile

To do: Create my signature with system and expected eGPU configuration information to give context to my posts. I have no builds.

.

fr34k liked
ReplyQuote
Brian Duchesneau
(@brian_duchesneau)
Eminent Member
Joined: 2 years ago
 

2012 mac mini - Sonnet box - RX 580

Still getting no screen output even after the 1.1.1 patch.  I ran system_profiler and see the following:

AppleGPUWrangler:

Version: 3.18.48
Last Modified: 8/25/17, 1:05 AM
Bundle ID: com.apple.AppleGPUWrangler
Loaded: No
Get Info String: 3.18.48, Copyright 2016-2018 Apple Inc. All rights reserved.
Obtained from: Unknown
Location: /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGPUWrangler.kext
Kext Version: 3.18.48
Loadable: No
Validity Errors:
Validation Failures:
File access failure; can't open, or I/O error: AppleGPUWrangler
Signature Validation Errors: Kext signature validation error code -1
Dependencies: Incomplete
Signed by: Unknown

2018 macmini i7 32GB/1TB SSD - OWC 650W - RX5700XT / Sonnet Breakaway Box RX/580 - OSX Catalina10.15.1 / Bootcamp


ReplyQuote
techyowl
(@techyowl)
Eminent Member
Joined: 3 years ago
 
Posted by: fr34k

@techyowl
The problem there is that you would have a process running constantly, draining energy

Theoretically, the kexts should be consistent throughout the systems, so:
What do you think about: (we're clean atm)
sha the .kext and store result at save place
patch
sha the new one and append
--- next execution (maybe after update)
sha kext and reference check
a) match with clean install -> use procedure above
b) match with patch -> patch (if needed, maybe update breaks something)
c) no match at all -> execute repair function for that update to restore clean install -> patch

drawback: a repair function would be needed for every possible update scenario (e.g: .3->.4, .3->.5, .4->.5 etc.)

The launchD shouldn’t run on interval only on startup no need to check for patch unless it’s a new startup since every update requires a reboot anyways.

SHA would be more reliable only issue is if the data store gets wiped by something if that’s the case it could build an SHA of an already patched kext and mark it as the Clean SHA why not simply look through the binary that we are modifying and make sure it matches the users thunder bolt version we are already detecting and if it matches do nothing (patch is already applied) if it doesn’t match the version but it does find thunder bolt 3 (current known unpatched state) then assume clean install if it finds nothing (patch won’t work due to massive variation likely from an os update) assume it cannot patch this os version and remove the auto patch launchD daemon. In the last case leave the backup in place and let the user make the decision whether to run a recovery if necessary. We could also store the os version when the backup was created and remove it when the version no longer matches to avoid potential corruptions in future MacOS changes. 

This will work for currently supported patchable os versions as we know what to expect. 

It should also fail gracefully when it breaks from a new os update that changes how the limits are put in place.

It will also apply the current known patch if it hasn’t patched it yet.

early-2015 13" MBP Retina + RX580@16Gbps-TB2 (AKiTiO Node via TB3->TB2 adapter)


ReplyQuote
mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 

@techyowl How about matching kext versions (from plist)? If a newer version is detected in /S/L/E/ first update backup, then proceed. Just a thought that popped up.

purge-wranglertbt-flashpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance

Master Threads:
2014 15-inch MacBook Pro 750M
2018 15-inch MacBook Pro

 
2019 13" MacBook Pro [8th,4C,U] + RX Vega 64 @ 32Gbps-TB3 (Mantiz Venus) + macOS 10.14.6 & Win10 [build link]  


techyowl liked
ReplyQuote
fr34k
(@fr34k)
Reputable Member Moderator
Joined: 2 years ago
 
Posted by: Blaine Miller
Posted by: fr34k

@techyowl
The problem there is that you would have a process running constantly, draining energy

Theoretically, the kexts should be consistent throughout the systems, so:
What do you think about: (we're clean atm)
sha the .kext and store result at save place
patch
sha the new one and append
--- next execution (maybe after update)
sha kext and reference check
a) match with clean install -> use procedure above
b) match with patch -> patch (if needed, maybe update breaks something)
c) no match at all -> execute repair function for that update to restore clean install -> patch

drawback: a repair function would be needed for every possible update scenario (e.g: .3->.4, .3->.5, .4->.5 etc.)

The launchD shouldn’t run on interval only on startup no need to check for patch unless it’s a new startup since every update requires a reboot anyways.

SHA would be more reliable only issue is if the data store gets wiped by something if that’s the case it could build an SHA of an already patched kext and mark it as the Clean SHA why not simply look through the binary that we are modifying and make sure it matches the users thunder bolt version we are already detecting and if it matches do nothing (patch is already applied) if it doesn’t match the version but it does find thunder bolt 3 (current known unpatched state) then assume clean install if it finds nothing (patch won’t work due to massive variation likely from an os update) assume it cannot patch this os version and remove the auto patch launchD daemon. In the last case leave the backup in place and let the user make the decision whether to run a recovery if necessary. We could also store the os version when the backup was created and remove it when the version no longer matches to avoid potential corruptions in future MacOS changes. 

This will work for currently supported patchable os versions as we know what to expect. 

It should also fail gracefully when it breaks from a new os update that changes how the limits are put in place.

It will also apply the current known patch if it hasn’t patched it yet.

true,
AFAIK one will need a way to omit uninstall before upgrade. Since an update will circumvent launchd. (I don't think a proper logout is performed so a logout hook will also not work...)
EDIT: I don't really know... must be tested. If so: hooray, else: meh.

macOS-eGPU.sh on GitHub (fr34k's macOS-eGPU.sh on eGPU.io)
----
2016 15'' MacBook Pro + GTX1080Ti@32Gbps-TB3 (Sonnet Breakaway 550) + macOS 10.13.6 (17G65 driver: 378.10.10.10.30.107 + CUDA: 396.148)


ReplyQuote
techyowl
(@techyowl)
Eminent Member
Joined: 3 years ago
 
Posted by: mac_editor

@techyowl How about matching kext versions (from plist)? If a newer version is detected in /S/L/E/ first update backup, then proceed. Just a thought that popped up.

That’s brilliant; definitely more reliable.

early-2015 13" MBP Retina + RX580@16Gbps-TB2 (AKiTiO Node via TB3->TB2 adapter)


ReplyQuote
fr34k
(@fr34k)
Reputable Member Moderator
Joined: 2 years ago
 

@techyowl
do you know if updates only do deltas on .kexts? or do the replace them completely?

macOS-eGPU.sh on GitHub (fr34k's macOS-eGPU.sh on eGPU.io)
----
2016 15'' MacBook Pro + GTX1080Ti@32Gbps-TB3 (Sonnet Breakaway 550) + macOS 10.13.6 (17G65 driver: 378.10.10.10.30.107 + CUDA: 396.148)


ReplyQuote
mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 
Posted by: fr34k

@techyowl
do you know if updates only do deltas on .kexts? or do the replace them completely?

Complete replacement.

purge-wranglertbt-flashpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance

Master Threads:
2014 15-inch MacBook Pro 750M
2018 15-inch MacBook Pro

 
2019 13" MacBook Pro [8th,4C,U] + RX Vega 64 @ 32Gbps-TB3 (Mantiz Venus) + macOS 10.14.6 & Win10 [build link]  


ReplyQuote
 of  164