MP 1,1-5,1 Cannot install or use Nvidia Webdrivers anymore!

[MacKing3000]

@Phaeton99 has not actually run the script and found that it does not work on LoSierra.
There is no reason why it would not work as of the current version posted

What you are seeing play out are the 'joys' of FOSS stuff:

1. @MacKing3000 mentioned that it crashes when he is running LoSierra but gave no actionable information.
   1. It was actually not a real error report as it was just mentioned in passing while talking about something else but let's call it one.
   2. As developer, you either have to chase for info or ignore such reports until something useful turns up.
      1. I chose the later
2. Based on that report however, @Phaeton99 concluded the script does not work on LoSierra
   1. You will note that he never actually tried running it
3. After the initial mention about crashing on LoSierra, @JohnBu, running HiSierra, gave a useful report by giving actionable info on a crash he was getting.
   1. This allowed a fix to go in and an update uploaded.
   2. It is not clear whether this was the same issue originally mentioned since as said, that report did not include any actionable information.

Summary is that there was an issue where on an iteration uploaded, the script stopped near the end and this has since been fixed. It affected everything: LoSierra, HiSierra, whatever.

I am installing a fresh version of Sierra on a new drive and will try run the script in its current state. Apologies for not ellaborating on the exact error.. the reason being is that I need to get back into that particular drive in SafeMode as the GPU drivers arent active and I’ve been getting the pixelated entry screen.. From what I recall the error was along the lines of -1 or 0 or something like that and would try to access the Folders and run the OCSP blocks that it automatically quit and didn’t actually run the script.. at least thats what it seemed liked. I will need to log back in and take screengrabs..

Just needed a break as it was a stressful few days trying to get it to work and realising that upgrading to High Sierra would render my current working version of Octane and C4D setup useless as the drivers wouldn’t work.

I think maybe what that script might need is a new automated task for the Sierra Cuda + driver install.. and perhaps the folder locks will work with the new fresh 10.12.6 install.. Here’s hoping thats the case

I am grateful to all the combined hard work from the developers to date getting the machines up and running, will loop back if i can get it Sierra working w script in current form

ERROR screengrab- attached

 

[hnieuw]

Hi guys,


Thanks for all the hard work here. Last half week was a nightmare for a lot of us. I am not brave enough to implement the script, as I am afraid it would lead me deeper into the rabbit hole and using my machine for work. Anyway, I fixed it by buying a cheap 2nd hand Radeon RX 570. Everything working smooth again in low siera. Hope for those that didn’t found a solution yet that it will work out soon.

Does anyone know how to prevent this in the future? Is there anything we should block with Little Snitch?



Good luck to all!

 

[flyproductions]

Wow, after a week of holiday (and away from the Mac), i am seriously overwhelmed of what happened to this thread!

First i have to send a big "thank you!" to anybody who put his effort in finding a solution or contacted NV to make them deliver one. In particular this goes to @Dayo who stepped in very early and basically got my machine up and running again just before i left.

Coming back, i was happy to find everything still running just fine. So, as long as there are no "very bad" things coming along with the early solutions, i plan to keep things untouched so far. But - for sure - will try to check all the progress in the next days to keep my info up to date. And hope to see some "real" solution by NV itself in the near future.

 

[tjnewt]

Things have moved on from blocking such connections

Thanks for the posted solutions

I’ve not had the problem since I found out early & blocked via hosts

To prevent it from happening to me in the future, what would be the difference (and pros/ cons) between running your script vs. blocking trustd using a utility like Radio Silence?

 

[truefaith90]

Enhanced the initial script to allow deactivating the locks if/when an official fix is issued, cover the spectrum of items needed and accommodate switching from the previous method in Post 82.

Firstly, ensure you have a backup that can be restored if required

Secondly, fully isolate your Mac from the web.

Thirdly, while not compulsory, boot into Safe Mode after fully isolating your Mac from the web. Safe Mode will enable a basic GPU driver that will, while not accelerated, allow you to operate your Mac without needing to swap GPUs. It is best to run the attached script while an affected GPU is connected.

More importantly perhaps, Safe Mode will purge several cert revocation caches which will make your life a lot easier later particularly when combined with being disconnected from the web.

To boot into Safe Mode, turn on or restart your Mac, then immediately press and hold the Shift key until you see the login window. Log in to your Mac (You might be asked to log in a second time).

You can verify you are in Safe Mode as follows

• Go to About This Mac >> System Report >> Software
• In the System Software Overview, look at the value listed next to the item labeled Boot Mode.
  • Safe: The Mac is using safe mode.
  • Normal: The Mac is not using safe mode.

Once in Safe Mode or otherwise ready, download the attached file, unzip it and double click to open it in the built in MacOS Script Editor. Once in Script Editor, click on the obvious button to run the script. Perhaps examine it first to see what it does. AppleScript is a "Near Regular English" scripting language and easy to follow.

If the script asks for confirmation on the paths it will work on, check the listed paths and make sure they all include either /C/com.apple.trustd or /T/com.apple.trustd. Click 'No' if any path does not and report the issue.

Reconnect to the web after running the script, reboot and you should be up and running.

If it does not immediately resolve your issues and you need to reinstall the web driver, run the following command in Terminal to fetch and run a script (from GitHub) for getting Nvidia Webdrivers directly from Nvidia: cd ~/Downloads && git clone https://github.com/corpnewt/Web-Driver-Toolkit && cd Web-Driver-Toolkit && chmod +x Run.command && ./Run.command.

The web driver will be saved in ~/Downloads/Web-Driver-Toolkit/Web Drivers. You should be able to install it without amendments but if this fails, run the following commands one after the other in Terminal to patch the driver and try installing again (best run the script again before reinstalling):

pkgutil --expand $HOME/Downloads/Web-Driver-Toolkit/Web Drivers/WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME.pkg $HOME/Downloads/Web-Driver-Toolkit/Web Drivers/WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME_temp.pkg
pkgutil --flatten $HOME/Downloads/Web-Driver-Toolkit/Web Drivers/WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME_temp.pkg $HOME/Downloads/Web-Driver-Toolkit/Web Drivers/WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME_patched.pkg
rm -fr $HOME/Downloads/Web-Driver-Toolkit/Web Drivers/WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME_temp.pkg

* Amend WEB_DRIVER_FOLDER_NAME/WEB_DRIVER_FILE_NAME as required

Alternatively, you could run the GitHub script BEFORE running this script and save the downloaded file directly under the Downloads folder as NvidiaWebDriver_Original. In such a case, the script will patch this file and save the patched version as NvidiaWebDriver_Patched.

To revert the changes made by the attached NvidiaWebdriverRevocationWorkaround script (if/when a proper fix is available), disconnect from the web, reboot into Safe Mode, install the fixed driver, run the script again and select the option to deactivate the workaround.

EDITS:
01. Lock/Unlock folders instead of contents
02. Misc Fine Tune
03. Structural Tweaks
04. Remove OCSP blocks in hosts file, Handle /Library/Keychains/crls
05. Misc Tidy Up
06. Reintroduce OCSP blocks in hosts file, Download and patch WebDriver-387.10.10.10.40.140
07. Prefers disconnection from the web, Prefers running under Safe Mode
08. Fixes missing 'WebDriver' variable
09. Misc Tidy Up
10. Remove web driver patching

Just created an account to say that you saved my a** tonight. I was really desperate when I found out that there is something wrong with my GPU again and was looking all over the place - was almost upgrading to Catalina with the Patcher to finally get CUDA running again. Never would I have thought that its an actual problem for all the users.... Thank you for putting together what you did there. Worked like a charm. <3 <3 <3

EDIT: Also mentioning that this was starting today. Was editing normally the whole week.

 

[funckdren]

Dayo, First off, thanks for all you've done here. You're a genius and have prevented many of us from going bald by tearing our hair out completely.

Second, I was up running fairly early in the game with your fix from Post #82. I see the new and improved fix in Post 461 -- if we've already done the earlier fix, can we just run the script from 461, or is there something we should do first?

 

[scannerfunk]

Just wanted to say thanks to @DTRX, @Macschrauber, @Dayo and everyone else that contributed to bringing (most of) our computers back into working order! Simply amazing work. Like many others, this has allowed my High Sierra machine to use my GPU properly, with no issues except for when Post #82 stopped working but was quickly remedied with Post #456 and Post #461.

I'd also like to chime in along with @Phaeton99 and @MacKing3000 that the scripts didn't work on my LoSierra machine. Post #82 worked for a few days but after a little while I assume things propagated and my GPU usage went down.

Here is some info if it helps:

Below: Earlier version of @Dayo script.

Below: Latest version of @Dayo script (as of 2022/06/12).

Below: @Macschrauber's test script.

Below: @Macschrauber 's full script.

All scripts were run in 10.12.6 Sierra with SIP disabled, in safe mode, and not connected to the internet.

Of course, no one is obligated to do anything with this info-- just hope that someone more able than me, feeling up to it and proactive, might be able to help some of the people that are still stuck on LoSierra for whatever reason.

Again, my thanks to the above mentioned and others who have helped thus far; hopefully this solution will work for awhile, or some other solution coming straight from Nvidia/Apple reveals itself. Here's hoping!

 

[Dayo]

the scripts didn't work on my LoSierra machine. Here is some info if it helps

Excellent. Something to work with.

Firstly though. The variations in the commands are trivial.

I added the brackets at some point while tidying some other stuff up as a coding style thing.
The biggest change, also trivial, is that @Macschrauber allows users to modify his script and add their password into the script. This is used when needed and they never get prompted for the password. If you don't make this amendment, the system will prompt you for your password when needed. I just prefer not to have this option in scripts and prefer that only the system handles passwords.

However, failing on that command, whichever variant - they all do exactly the same thing, is significant as it means /private/var/folders either simply does not exist on LoSierra/Earlier (most likely) or is totally locked down (most unlikely).

The latest iterations of the Post 461 scripts roll a beefed up /etc/hosts blocking from Post 82 into the @DTRX solution. I will tweak the script to only rely on /etc/hosts blocking on LoSierra and earlier. If a user needs to reinstall the drivers, possible need mainly on LoSierra/Earlier, then there are already instructions on how to go about this with the help of a script from CorpNewt on GitHub.

If the solution ever stops working, whether on Lo/HiSierra or something else, it should be possible to rerun the script after disconnecting and rebooting into Safe Mode to reactivate things.

 

[Macschrauber]

Yes, I like to have the option to store the password in the script.

it is not necessary of course.

And it is also not secure, I use it for my test machines where no personal data is stored.

 

[Dayo]

Updated the the script in Post 461 to v11.
Basically handles some errors to broaden support coverage.

As always, there is no need to change anything on a working setup.

 

[Dayo]

Post #82 worked for a few days but after a little while I assume things propagated and my GPU usage went down.

Just running with this.

Seems to fit into a clear pattern that the host blocking by itself is basically a short term fix. While the time to manifestation might vary for different people, it is there all the same. The number of failed connection attempts is being saved and this can't just be for the fun of it.

My hypothesis is that this data, along with data on time frames, is used by the SysPolicy process, which runs at as yet unclear intervals, to take some actions. I guess the first thing would be to simply try another validation subdomain.

The script now blocks all known validation subdomains in adding to locking the caches. This should dramatically extend the time span before things stop again. Yes, I believe things could still ultimately stop even with the cache locking in place as there appear to still be locations where info goes ... especially if you boot into a different account.

It should be possible to reset the clock by rerunning the process.
We will have to wait and see.

 

[DTRX]

Just wanted to say thanks to @DTRX, @Macschrauber, @Dayo and everyone else that contributed to bringing (most of) our computers back into working order! Simply amazing work. Like many others, this has allowed my High Sierra machine to use my GPU properly, with no issues except for when Post #82 stopped working but was quickly remedied with Post #456 and Post #461.

I'd also like to chime in along with @Phaeton99 and @MacKing3000 that the scripts didn't work on my LoSierra machine. Post #82 worked for a few days but after a little while I assume things propagated and my GPU usage went down.

Here is some info if it helps:

Below: Earlier version of @Dayo script.
View attachment 2018382
Below: Latest version of @Dayo script (as of 2022/06/12).
View attachment 2018383
Below: @Macschrauber's test script.
View attachment 2018386
Below: @Macschrauber 's full script. View attachment 2018387

All scripts were run in 10.12.6 Sierra with SIP disabled, in safe mode, and not connected to the internet.

Of course, no one is obligated to do anything with this info-- just hope that someone more able than me, feeling up to it and proactive, might be able to help some of the people that are still stuck on LoSierra for whatever reason.

Again, my thanks to the above mentioned and others who have helped thus far; hopefully this solution will work for awhile, or some other solution coming straight from Nvidia/Apple reveals itself. Here's hoping!

This adds up to my assumption as written in post 545. "Low" Sierra and High Sierra obviously have differences in their trustd implementation leading to changes in folder structure or renamed temporary folders created by this deamon. Still, I do not have access to a "Low" Sierra machine to find a custom fix.

 

[DTRX]

Just running with this.

Seems to fit into a clear pattern that the host blocking by itself is basically a short term fix. While the time to manifestation might vary for different people, it is there all the same. The number of failed connection attempts is being saved and this can't just be for the fun of it.

My hypothesis is that this data, along with data on time frames, is used by the SysPolicy process, which runs at as yet unclear intervals, to take some actions. I guess the first thing would be to simply try another validation subdomain.

The script now blocks all known validation subdomains in adding to locking the caches. This should dramatically extend the time span before things stop again. Yes, I believe things could still ultimately stop even with the cache locking in place as there appear to still be locations where info goes ... especially if you boot into a different account.

It should be possible to reset the clock by rerunning the process.
We will have to wait and see.

As told many times before, I found the hosts fix being too unreliable for myself. During my tests I found the solution with folder locking to be a permanent fix for one setup, as long as your High Sierra installation is running with the same machine. If you clone the startup disk and move it to another compatible Mac with a similar NVIDIA GPU setup, web drivers will be again blacklisted, because a new machine-specific temporary folder will be created in /private/var/folders. In this case, your script needs to be re-executed, to find the newly created com.apple.trustd directories, with subsequent content removal and locking.

 

[MacKing3000]

Just wanted to say thanks to @DTRX, @Macschrauber, @Dayo and everyone else that contributed to bringing (most of) our computers back into working order! Simply amazing work. Like many others, this has allowed my High Sierra machine to use my GPU properly, with no issues except for when Post #82 stopped working but was quickly remedied with Post #456 and Post #461.

I'd also like to chime in along with @Phaeton99 and @MacKing3000 that the scripts didn't work on my LoSierra machine. Post #82 worked for a few days but after a little while I assume things propagated and my GPU usage went down.

Here is some info if it helps:

Below: Earlier version of @Dayo script.
View attachment 2018382
Below: Latest version of @Dayo script (as of 2022/06/12).
View attachment 2018383
Below: @Macschrauber's test script.
View attachment 2018386
Below: @Macschrauber 's full script. View attachment 2018387

All scripts were run in 10.12.6 Sierra with SIP disabled, in safe mode, and not connected to the internet.

Of course, no one is obligated to do anything with this info-- just hope that someone more able than me, feeling up to it and proactive, might be able to help some of the people that are still stuck on LoSierra for whatever reason.

Again, my thanks to the above mentioned and others who have helped thus far; hopefully this solution will work for awhile, or some other solution coming straight from Nvidia/Apple reveals itself. Here's hoping!

Thanks for sharing the info! This is exactly the ERROR I was getting. If anyone could shine a light on LoSierra fix would be amazing. Still unable to run Cuda + Driver combo for C4D + Octane which is mainly what the machine is being used for. It’s running a Titan X Mac Flashed Card + 1080ti. I am able to activate the attached CUDA + Driver Combo for Sierra but they are not recognised by C4D - and I'm not sure if these will break again in several days time.. I was able to install these right after a fresh SIERRA on a new drive. I did try to update to a higher CUDA version and Higher Driver but I get the > ( Package can't be opened move it to the trash ) message.

 

[MacKing3000]

Also .. has anyone found a way to run 1080ti or Titan X card w current fix + HighSierra ? If so, which driver + Cuda combo are you using? And which version of C4D & Octane? Just trying to find a workaround to get 3D working..

 

[Dayo]

As told many times before, I found the hosts fix being too unreliable for myself. During my tests I found the solution with folder locking to be a permanent fix for one setup, as long as your High Sierra installation is running with the same machine. If you clone the startup disk and move it to another compatible Mac with a similar NVIDIA GPU setup, web drivers will be again blacklisted, because a new machine-specific temporary folder will be created in /private/var/folders. In this case, your script needs to be re-executed, to find the newly created com.apple.trustd directories, with subsequent content removal and locking.

As also mentioned a few times now, rerunning the script should reset things and the hosts file fix will almost certainly fail at some point as it stands.

Your case, where the host file fix appears to be totally unreliable, seems to be an edge case. For most, it appears to work for a reasonable amount of time but yes, it will almost certainly fail sooner or later, at which point a rerun of the script will be needed. The script will take care of things if the host file fix had been manually applied. This is whether it is the 2 host setup, a 3 host one or any other number of the published validation hosts. It also doesn't matter whether 0.0.0.0 or 127.0.0.1 was used.

What the script does is to apply both methods as I am not sure cache locking is in fact a permanent fix at this time. This is because information on Soft Failures (e.g. failure to connect) and Hard Failures (not exactly sure what these are but a failure to write output seems to be a likely fit) is being collected in locations that are not currently covered by the process. I don't think this info is being collected for the fun of it.

Either way, I am simply a pragmatist and not tied to one approach or the other. The aim is simply to get the units up and running whichever way works.

For people on LoSierra, the cache locking currently fails and the script will degrade to only implementing the host file block (all known hosts ... hopefully this includes all in use for that MacOS version). If/when this stops to work, they can rerun and be back up again. If cache locking can be done later, it will be added.

For those on HiSierra, it implements both ways together. If it similarly does stop to work (should be a very long time if it happens) they should be able to similarly rerun and be good. If the cache lock is in fact a permanent fix, then there is nothing lost.

Main thing that is missing is that instead of simply running the script and being happy that things work, people should be pestering Nvidia for a fix. If their support centre was getting 100,000 calls a day, you can be sure they will wake up.

 

[Dayo]

If anyone could shine a light on LoSierra fix would be amazing.

Updated the the script in Post 461 to v11.
Basically handles some errors to broaden support coverage.

As always, there is no need to change anything on a working setup.

 

[DTRX]

As also mentioned a few times now, rerunning the script should reset things and the hosts file fix will almost certainly fail at some point as it stands.

Your case, where the host file fix appears to be totally unreliable, seems to be an edge case. For most, it appears to work for a reasonable amount of time but yes, it will almost certainly fail sooner or later, at which point a rerun of the script will be needed. The script will take care of things if the host file fix had been manually applied. This is whether it is the 2 host setup, a 3 host one or any other number of the published validation hosts.

What the script does is to apply both methods as I am not sure cache locking is in fact a permanent fix at this time. This is because information on Soft Failures (e.g. failure to connect) and Hard Failures (not exactly sure what these are but a failure to write output seems to be a likely fit) is being collected in locations that are not currently covered by the process. I don't think this info is being collected for the fun of it.

Either way, I am simply a pragmatist and not tied to one approach or the other. The aim is simply to get the units up and running whichever way works.

For people on LoSierra, the cache locking currently fails and the script will degrade to only implementing the host file block (all known hosts). If/when this stops to work, they can rerun and be back up again. If cache locking can be done later, it will be added.

For those on HiSierra, it implements both ways together. if it similarly does stop to work (should be a very long time if it happens) they should be able to similarly rerun and be good. If the cache block is in fact permanent, then there is nothing lost.

Main thing that is missing is that insteadd of simply running the script and being happy that things work, people should be pestering Nvidia for a fix. If their support centre was getting 100,000 calls a day, you can be sure they will wake up.

Just curious, to all: Has anyone running "Low" Sierra restored a working setup just with blocking hosts/trustd using Little Snitch?

 

[MacKing3000]

Dayo said:
Updated the the script in Post 461 to v11.
Basically handles some errors to broaden support coverage.

As always, there is no need to change anything on a working setup.
——————-


Legend thank you mate! Will give this another go.

 

[DTRX]

If anyone could shine a light on LoSierra fix would be amazing.

Some new light from me:

"Low" Sierra has indeed a different implementation of the kext blocking mechanism. No com.apple.trustd folders can be found (this is the reason for throwing errors in the current script version running under "Low Sierra"). Instead the trustd deamon creates a few files in various directories with the following structure:

/private/var/folders/%TEMPNAME%/%TEMPNAME%/%TEMPNAME%/ocspcache.sqlite3
/private/var/folders/%TEMPNAME%/%TEMPNAME%/%TEMPNAME%/ocspcache.sqlite3-shm
/private/var/folders/%TEMPNAME%/%TEMPNAME%/%TEMPNAME%/ocspcache.sqlite3-wal

/private/var/root/Library/Keychains/%UUID%/ocspcache.sqlite3
/private/var/root/Library/Keychains/%UUID%/ocspcache.sqlite3-shm
/private/var/root/Library/Keychains/%UUID%/ocspcache.sqlite3-wal

/Users/%USERNAME%/Library/Keychains/%UUID%/ocspcache.sqlite3
/Users/%USERNAME%/Library/Keychains/%UUID%/ocspcache.sqlite3-shm
/Users/%USERNAME%/Library/Keychains/%UUID%/ocspcache.sqlite3-wal

The actual files present on a "Low" Sierra installation can be discovered using a root shell via "find / -name 'ocspcache*'".

Steps to break trustd's functionality would be removing the files one by one and again touching the exact file paths to create multiple empty placeholder files. Those are to be locked subsequently by "chflags uchg". Dayo will know how to script this.

I am not sure if this solution will work, since I discovered this from a VM of latest "Low" Sierra 10.12.6 (16G2136) with all available patches applied and no NVIDIA GPU and web drivers present. The brave would need to test and see if it leads to changes in the driver blocking status.

@MacKing3000: Sorry for not being sure about if the above will be actually helpful in your situation. But you could still give it a try.

 

[Dayo]

Nice work.

The script already clears the ~/Library/Keychains/*/ocspcache.sqlite3 file

I will update this to v12 later and this will also clear /private/var/folders/*/*/*/ocspcache.sqlite3 and /private/var/root/Library/Keychains/*/ocspcache.sqlite3 but will leave it at that and let the host file blocks deal with preventing updates for now.

I assume these are all flushed when a user boots into Safe Mode as well but specifically clearing them would make sure.

It is possible to get the paths using that command and process them but it is a bit more involved (will need to change "find /" to "find /Path/to/Partial/Point/" and change the path to reduce time. Then combine them all into one list and loop over that).

Might tackle that later but I think that LoSierra should already be largely covered as of the v11 script. Will see what reports come in on that.

EDIT:
Found a compromise.
Instead of deleting stuff, the script now also flushes the other two databases and then locks them all.
The encrypted databases are also locked.

 

[pxlpshr22]

If it does not immediately resolve your issues and you need to reinstall the web driver, run the following command in Terminal to fetch and run a script (from GitHub) for getting Nvidia Webdrivers directly from Nvidia: cd ~/Downloads && git clone https://github.com/corpnewt/Web-Driver-Toolkit && cd Web-Driver-Toolkit && chmod +x Run.command && ./Run.command.

Thanks for all of the work you have done! I am having an issue with the download. Is there another repository?

 

[Dayo]

Updated the the script in Post 461 to v12.
Basically flushes OCSP entries from some cache dbs and then locks them on LoSierra/Earlier.

As always, there is no need to change anything on a working setup.

 

[Dayo]

Is there another repository?

No. You can try again later.

In any case, it might be better to spell out what the issue you have after running the script is and what you are using.
Script version, OS version etc

 

[pxlpshr22]

No. You can try again later.

In any case, it might be better to spell out what the issue you have after running the script is and what you are using.
Script version, OS version etc

macOS 10.13.6 (17G14042)
NVIDIA GeForce GTX 980
Boot ROM Version: 144.0.0.0.0

Ran the script, the Driver Manager in the Preference panels returned/accessible. CUDA Preferences reports No GPU Detected.