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

[Dayo]

whats the "this" they are referring to? im utterly confused.

That's a different issue to previously not seeing any such posts.

As for the "this", I suppose you need to check those posts and look at the context the user posted within.
To help you out, they are basically following the steps in the post on Page 4.

This has been updated and is perhaps slightly different to when you first tried it out for reasons explained here:

https://forums.macrumors.com/threads/cannot-install-or-use-nvidia-webdrivers-anymore.2346445/post-31161694

An alternative presentation of the same information is here:

https://forums.macrumors.com/threads/cannot-install-or-use-nvidia-webdrivers-anymore.2346445/post-31147885

In summary, you need to disconnect your machine, boot into Safe Mode (or revert to a backup from before 31 May 2022) and implement the steps listed ... mainly blocking OCSP

 

[adriandegar]

Right,

Been looking at things trying to understand what was happening with the varying outcomes seen and think I have finally figured it out.

It appears that there are two broad categories people can fall into:

1. Those that did not try to reinstall the web drivers when they noticed issues
2. Those that tried to reinstall the web drivers when they noticed issues

For those that did not try to reinstall, recovery was/is as simple as blocking OCSP (adding ocsp.digicert.com appears to be a red herring and it is the Apple ones that apparently matter), clearing the OCSP Cache in /var/db/crls, rebooting and Bob's your uncle. You could do the date shuffle just for making sure all is ship shape.

Those that tried reinstalling however, simply dug themselves deeper in the quicksand and it needed a bit more to get out of the mire.

Apparently, when a pkg file is being installed (or at least some pkg files), the installation is done in a sandbox and in this case, the Certificate Revocation status is stored in an associated System-Access-Only folder here: /private/var/folders/zz. I haven't been able to look into the files there in detail but I am sure it includes other items or hashes that identify the file in question; which I assume is why the cert stripping attempts did not quite work as expected.

It is actually a temporary folder, a cache, but manually flushing it is definitely a bad idea as some items appear to sit there for a long time.

Every time you try to install the same file again, it hits this info and halts.

Options to get past this are (After blocking OCSP, going offline and clearing the regular /var/db/crls cache):

1. Reinstall the OS and migrate your system data over. This apparently does not bring this cache along.
2. Run a tool such as OnyX and hope it clears this cache
3. Revert to a backup from before the sandbox file was created
4. Reboot into Safe Mode. This apparently purges this cache
5. Delete the contents of /private/var/folders/zz manually and hope you can still boot afterwards
   • I suppose you could try overwriting it with one from backup and similarly hope it works

Boot into Safe Mode seems the best of the lot. Alternative is to roll back to before 31 May 2022.
Important thing is that OCLP should be blocked before any fix attempt. Best to do any fixes while offline.

I will update The Post on Page 4 Presently

Yes I’d say this is spot on. I actually had an old CCC clone of my main drive which had the driver pkg and I had attempted to open it from my tainted drive. Of course it didn’t load. The interesting part was when I cloned that CCC image and booted from it offline the kexts wouldn’t load either, so it spread pretty nefariously and ruined that image.

Figured the data would be in a system access only folder. How do you get into those? Even with sudo I couldn’t get in them.

 

[Dayo]

How do you get into those? Even with sudo I couldn’t get in them.

No idea. That's why I have been unable to examine the contents.
Might be tied to SIP. Didn't bother to go to the Nth degree on it.

 

[Fullerfun]

Right,

Been looking at things trying to understand what was happening with the varying outcomes seen and think I have finally figured it out.

It appears that there are two broad categories people can fall into:

1. Those that did not try to reinstall the web drivers when they noticed issues
2. Those that tried to reinstall the web drivers when they noticed issues

For those that did not try to reinstall, recovery was/is as simple as blocking OCSP (adding ocsp.digicert.com appears to be a red herring and it is the Apple ones that apparently matter), clearing the OCSP Cache in /var/db/crls, rebooting and Bob's your uncle. You could do the date shuffle just for making sure all is ship shape.

Those that tried reinstalling however, simply dug themselves deeper in the quicksand and it needed a bit more to get out of the mire.

Apparently, when a pkg file is being installed (or at least some pkg files), the installation is done in a sandbox and in this case, the Certificate Revocation status is stored in an associated System-Access-Only folder here: /private/var/folders/zz. I haven't been able to look into the files there in detail but I am sure it includes other items or hashes that identify the file in question; which I assume is why the cert stripping attempts did not quite work as expected.

It is actually a temporary folder, a cache, but manually flushing it is definitely a bad idea as some items appear to sit there for a long time.

Every time you try to install the same file again, it hits this info and halts.

Options to get past this are (After blocking OCSP, going offline and clearing the regular /var/db/crls cache):

1. Reinstall the OS and migrate your system data over. This apparently does not bring this cache along.
2. Run a tool such as OnyX and hope it clears this cache
3. Revert to a backup from before the sandbox file was created
4. Reboot into Safe Mode. This apparently purges this cache
5. Delete the contents of /private/var/folders/zz manually and hope you can still boot afterwards
   • I suppose you could try overwriting it with one from backup and similarly hope it works

Boot into Safe Mode seems the best of the lot. Alternative is to roll back to before 31 May 2022.
Important thing is that OCLP should be blocked before any fix attempt. Best to do any fixes while offline.

I will update The Post on Page 4 Presently

Pretty close. however, for me, I never re-installed the drivers, but I HAD to boot to safe mode. Just blocking and then clearing OCSP (not in safe made) did not work. I'm pretty sure booting in safe mode clears some other cache...(It might be dyld cache..which is just a quess..but i do know that trustd does use dyld cache)...and once that happened, everything came back to life. Same EXACT thing worked for a friend of mine with a similar setup to me. Been rock solid ever since for a good day & a half now.

 

[Fullerfun]

No idea. That's why I have been unable to examine the contents.
Might be tied to SIP. Didn't bother to go to the Nth degree on it.

Go into /private/var/folders/ the current folder being used will be different 2 letters/numbers for everyone...navigate a few folders in to com.apple.trustd In there you will find sqlite3 database files, some of which are password protected(good luck cracking into those). Fairly sure these are database files that trustd uses to determine which programs and kexts are "Allowed" to run on the system.(it's probably way more complicated than I'm saying...and those databases might get some of their info from other caches, keychains, and other databases,) This is also when I discovered that trustd uses DYLD cache as well. Anyway this is all a road I went down before trying to simply boot safe mode.

 

[raoultesla]

Right,

It seems the answer is to simply completely disable all certificate revocation checks.
Not typically something recommended but I suppose it makes little difference when running HiSierra.

First, you need to boot into Safe Mode. This will enable a basic GPU driver that will, while not accelerated, allow you to operate your Mac. To do this, turn on or restart your Mac, then immediately press and hold the Shift key until you see the login window and 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, carry out the following steps:

1. Download the web drivers in case you need to reinstall them
   • Only directly from the Nvidia website
2. Fully disconnect your Mac from the web
3. Run sudo sh -c 'echo "0.0.0.0 ocsp.apple.com" >> /etc/hosts' && sudo sh -c 'echo "0.0.0.0 ocsp2.apple.com" >> /etc/hosts' && sudo killall -HUP mDNSResponder in Terminal
4. Run crlrefresh rp && sudo rm -f /var/db/crls/* && sudo sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM ocsp;' (AKA Purge Command) in Terminal to purge the current cached Certificate Revocation List
   • Ignore any error messages on running the above
5. Run date -u 120200002021 && sudo reboot (AKA Date Command) in Terminal
6. Reconnect to the web and you should be good
   • If not good, disconnect from the web, rerun the purge and date commands above (in that order) and then reinstall the drivers before reconnecting
     • You may want to go into Safe Mode first
     • Disregard any cert stripping steps you may have come across
   • If not good, disconnect from the web, rerun the purge and date commands above (in that order) and then restore a backup from before 31 May 2022 before reconnecting
   • If still not good, rerun the purge and date commands above (in that order) and stay offline
     • You may want to go into Safe Mode

EDIT:
To revert the changes (if/when a proper fix is available), you will need to...

1. Open Terminal, type sudo nano /private/etc/hosts and press "Enter"
   • I use Nano and forget what the default editor in Terminal is
   • If you don't have Nano, I think vim is most likely the default.
2. Delete the ocsp lines; then save and close
3. Run sudo killall -HUP mDNSResponder && sudo reboot in Terminal to refresh the DNS cache and reboot

OK, if anyone doubts you again, just call me.
I am

I did as instructed above. It works immediately. Restarted into standard mode, No Connection. nVidia icon is in top menu of desktop.

Went into preferences, nVidia Driver pane opened normal, allowed me to switch to Dedicated nVidia driver, away from 'integrated' Apple driver.
I trust you, I do NOT turst nVidia nor Apple, so will disconnect if need restart. I know, I know disabled ocsp...

This is what Terminal with Dayo instuctions looks like. This exact Terminal input Worked !
~~~
MBP4:~ USERNAME$ sudo sh -c 'echo "0.0.0.0 oscp.apple.com" >> /etc/hosts' && sudo sh -c 'echo "0.0.0.0 ocsp2.apple.com" >> /etc/hosts' && sudo killall -HUP mDNSResponder
Password:
MBP4:~ USERNAME$ crlrefresh rp && sudo rm -f /var/db/crls/* && sudo sqlite3 ~/Library/Keychains/*/ocspache.sqlite3 'DELETE FROM ocsp;'
Error: unable to open database "/Users/paultreseler/Library/Keychains/*/ocspache.sqlite3": unable to open database file
MBP4:~ USERNAME$ date -u 120200002021 && sudo reboot
date: bind: Permission denied
date: settimeofday (timeval): Operation not permitted
MBP4:~ USERNAME$
~~~~

Thanks again Dayo
Going to forward this to another thread of MacPro guys who I think have not seen your posts/genious.
There are many of us who Need to use our 'dated' yet loved, machines for work.
Cheers man

 

[tripleVertex]

The below steps will resolve your issue at the cost of waiving the operating system’s ability to block signatures revoked for legit security reasons. If you have previously tampered with an affected system, please revert to the most recent Time Machine backup (no manual signature-stripping or hauling around of system files).

Step 1. Physically disconnect the affected device from the web. Powering down the router for a few minutes will do just fine.

Step 2. Boot into Safe Mode. Everything will be extremely laggy, be patient.

Step 3. Launch Terminal and enter the command ‘sudo nano /etc/hosts’, once prompted provide the password.

Step 4. Append the following lines to the file’s contents:

127.0.0.1 ocsp.apple.com
127.0.0.1 ocsp2.apple.com
127.0.0.1 ocsp.digicert.com

Save changes and exit.

Step 5. Run the following batch of Terminal commands:

crlrefresh rp
sudo rm -f /var/db/crls/*cache?.db
sudo date -u 020200002020
sudo reboot

Your computer will immediately reboot after the last command. Upon seeing the desktop again, you should notice that everything is back to normal. You can now reconnect to the internet. System time and date will automatically adjust themselves upon reconnecting. If some apps throw errors related to bad time and date, another reboot will fix that. Don’t worry if you run into any scary messages upon the first reboot.

The ‘sudo date’ shift trick is 90% likely unnecessary but better safe than sorry. It’s there just to lure the system (now reverted to a clean state) into repeating any sneaky moves it’s compelled to make since the 1st of June, just to check it no longer breaks itself.

that so far worked for me (still testing) the Nvidia Driver started to work again for 10.13.6 - thank you so much! - So I understand that the computer is now more vulnerable? 3rd party apps..? would you be so kind and tell us what 'vulnerability' we have to expect after running these terminal commands.. ? again - many many thanks to you !!

 

[Frixo Cool]

Thanks eierfrucht - your method worked great and it's very simple.

P.S.
You have a free guided tour to our Computer Museum if you ever come to vacation in Croatia!

 

[mirko.meschini]

Hello guys, I'm from Italy and a couple of years ago I made some hackintoshes for my customers (first times with Nvidia Pascal GPUs, then I switched to Radeons), so on 3rd June morning I found all them on front of my lab, all with their computers!! Not so funny
Now I found this solution, on page4 of this thread. All ok, but I can't fix them without reinstalling a fresh copy of high sierra, block ocsp in /etc/hosts, set date on 2021 and installing Security Update 2019-002 (17G6030) then the relative version of Nvidia web drivers, a little time consuming for tens of installations...
To fix an already bricked installation I tried all solutions, none works. After webdrivers got blacklisted I can't unlock them. Any ideas?

 

[Terry 44]

Hello guys, I'm from Italy and a couple of years ago I made some hackintoshes for my customers (first times with Nvidia Pascal GPUs, then I switched to Radeons), so on 3rd June morning I found all them on front of my lab, all with their computers!! Not so funny
Now I found this solution, on page4 of this thread. All ok, but I can't fix them without reinstalling a fresh copy of high sierra, block ocsp in /etc/hosts, set date on 2021 and installing Security Update 2019-002 (17G6030) then the relative version of Nvidia web drivers, a little time consuming for tens of installations...
To fix an already bricked installation I tried all solutions, none works. After webdrivers got blacklisted I can't unlock them. Any ideas?

Hello
I've done that for my macpro 3.1 with 970GTX build (17G14033) WebDriver-387.10.10.10.40.139 and cudadriver_418.105_macos all from nvidia site

https://forums.macrumors.com/thread...idia-webdrivers-anymore.2346445/post-31147885

and I use also this

GitHub - corpnewt/Web-Driver-Toolkit: A small python script for downloading NVIDIA Web Drivers based on either the current OS build version - or a selected build version.

A small python script for downloading NVIDIA Web Drivers based on either the current OS build version - or a selected build version. - corpnewt/Web-Driver-Toolkit

github.com

Success until now after 5-6 reboot and internet connection

 

[mirko.meschini]

Hello
I've done that for my macpro 3.1 with 970GTX build (17G14033) WebDriver-387.10.10.10.40.139 and cudadriver_418.105_macos all from nvidia site

https://forums.macrumors.com/thread...idia-webdrivers-anymore.2346445/post-31147885

and I use also this

GitHub - corpnewt/Web-Driver-Toolkit: A small python script for downloading NVIDIA Web Drivers based on either the current OS build version - or a selected build version.

A small python script for downloading NVIDIA Web Drivers based on either the current OS build version - or a selected build version. - corpnewt/Web-Driver-Toolkit

github.com

Success until now after 5-6 reboot and internet connection

Tried, not working. I need to reinstall a fresh copy of macOS to get it working again.

 

[Dayo]

To fix an already bricked installation I tried all solutions, none works. After webdrivers got blacklisted I can't unlock them.

Look at it like gangrene. Once the rot has spread beyond a certain degreee, there is no fix without amputation.

You need a MacOS instance that does not include the revocation status in certain system locations.
This is either by restoring a backup from before 31 May 2022 or by installing MacOS and migrating data.

Of course, the Almighty (Apple and/or Nvidia) could heal any and every thing but self help is always batter than waiting for divine intervention.

 

[eierfrucht]

I had SIP disabled, but the code signing (as you mentioned) was useless because the kexts and pkg files in the installed were already blocked by obfuscated local reference(s) to the revocation

So it looks like a hash block stemming from the other cache that Dayo pinpointed? He says booting into Safe mode before blocking ocsp is enough to reset that cache, will your Mac boot normally if you redo the signing routine like that?

Anyway ad hoc signing seems like a very convoluted solution that also wants SIP off...

 

[beyond]

Huh??

 

[eierfrucht]

that so far worked for me (still testing) the Nvidia Driver started to work again for 10.13.6 - thank you so much! - So I understand that the computer is now more vulnerable? 3rd party apps..? would you be so kind and tell us what 'vulnerability' we have to expect after running these terminal commands.. ? again - many many thanks to you !!

Apps and kexts that had their signatures revoked by Apple for whatever reason will suddenly start working again. If stuff gets blocked because it makes your system vulnerable or is outright malicious, disabling that watchdog exposes you to the risk of installing and running said bad stuff unalerted.

Look at it like gangrene. Once the rot has spread beyond a certain degreee, there is no fix without amputation.

I’m confused. Didn't you just prove it was all about another previously undiscovered cache that properly resets itself after booting in Safe Mode? Someone in this thread reported successfully reinstalling the drivers while in Safe, without any extra steps.

By the way, someone mentioned DYLD cache. As far as I can remember, the proper way if resetting it was:

sudo update_dyld_shared_cache -debug

to unlink some leftovers from earlier updates, then

sudo update_dyld_shared_cache -root / -force

To rebuild it cleanly.

Make if it what you will. It can also be the thing that happens whenever you boot in Safe Mode.

 

[mirko.meschini]

for more infos, on my hackintoshes I have SIP disabled via Opencore, but I don't boot in safe mode (I don't know how to do), I can boot on bricked machines with nvda_drv_vrl=0 and nv_disable=1

 

[TedsterTheSecond]

Okay I had a go, some of my terminology might be a bit suspect!!!

 

[eierfrucht]

Damn, we are cooked. Even Krishna himself can’t do jack **** about it without addressing his Higher Team,I what on a cosmic scale that might even be?

for more infos, on my hackintoshes I have SIP disabled via Opencore, but I don't boot in safe mode (I don't know how to do), I can boot on bricked machines with nvda_drv_vrl=0 and nv_disable=1

This will either force VESA or Apple’s notarized drivers for the few Nvidia cards officially supported by Apple.

I also use Opencore but never lower SIP down because I consider it bad practice and a security risk.

I've done that for my macpro 3.1 with 970GTX build (17G14033) WebDriver-387.10.10.10.40.139 and cudadriver_418.105_macos all from nvidia site

You need to stop beating about the bush, hop off your derelict High Sierra build and go for Opencore Legacy Patcher to install the latest HS on your long-supported MacPro3,1: https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html

You have already wasted more time and thread space than you would have spent on doing a proper 17G14042 install.

No idea. That's why I have been unable to examine the contents.

Unless you are on Apple Silicon, you could snatch a copy of Parted Magic then boot into it off a USB stick. It lets you peek into all sorts of filesystems including APFS while the guards are off. PM me for a link if you have trouble running / installing Parted Magic.

I also suppose any kind of Ubuntu Live USB will do, APFS has been supported (even if as just read-only) for quite a while. I'm not dead sure though.

 

[Dayo]

I’m confused.

He claimed to have tried the steps and it didn't work.

While I very well know from experience in supporting stuff that what people say they have done in such situations is often of next to no value (logs or it didn't happen is my motto), if he does say he has and it didn't work, then he needs to move on to steps that make sure there is no way anything can be present.

Not something being suggested for everyone across the board; just relevant to his case as it appears he must have the rot running deeper (if he took the steps correctly). Either way, taking those additional actions will definitely sort him sort.

EDIT:

By the way, someone mentioned DYLD cache. As far as I can remember, the proper way if resetting it was:
sudo update_dyld_shared_cache -debug
to unlink some leftovers from earlier updates, then
sudo update_dyld_shared_cache -root / -force
To rebuild it cleanly.
Make if it what you will. It can also be the thing that happens whenever you boot in Safe Mode.

MAN page for update_dyld_shared_cache says the cache is purged on booting into Safe Mode.

 

[Fullerfun]

for more infos, on my hackintoshes I have SIP disabled via Opencore, but I don't boot in safe mode (I don't know how to do), I can boot on bricked machines with nvda_drv_vrl=0 and nv_disable=1

You are having problems because you never boot in safe mode. Don’t know how? You could use Google to figure it out for opencore. try -x boot flag. Just booting with nv_disable=1 will not fix it.

 

[mirko.meschini]

Okay I had a go, some of my terminology might be a bit suspect!!! View attachment 2015884 View attachment 2015885 View attachment 2015886 View attachment 2015887 View attachment 2015888

2 or 3 chats later you'll talk with Jensen

 

[bllx]

Have you tried this too?

sudo nvram nvda_drv=0

It will force system to use build-in drivers instead of nVidia Web ones... Will be without acceleration for sure because GTX 970 is not natively supported. Also, you may need to have another nVidia supported card on other slot (like GT-120 etc...)

Yes I added that arg to the nvram as well -still no video output from the 970.

So I'm running the Mac Pro's original Radeon 5770 1GB card in slot 2 and my nVidia 970 in Slot 1; this means I use macOS via the Radeon, but can still use the 970 (and the Radeon too BTW) in Windows for gaming (which was its original purpose). The computer has to work harder to keep temps down now that I have 2 full length PCI cards next to each other: when gaming in Windows the fans are very loud, but temps acceptable: I recently re-pasted Northbridge and CPU.

This is something I keep quiet, that my old Mac Pro can now use all its hardware only in Windows, not in its own macOS.

 

[mirko.meschini]

However I'm ok with this solution, fresh install, block ocps and webdrivers. It seems changing date is not required at all. All machines I made years ago with nVidia cards are Clover installs, so It's a good time to switch all them to Opencore

 

[adriandegar]

However I'm ok with this solution, fresh install, block ocps and webdrivers. It seems changing date is not required at all. All machines I made years ago with nVidia cards are Clover installs, so It's a good time to switch all them to Opencore

The date change was not needed for me. I think it’s not doing much at all. I did fresh install and blocked ocsp then migration assistant to pull the information from the broken drive.

 

[adriandegar]

So it looks like a hash block stemming from the other cache that Dayo pinpointed? He says booting into Safe mode before blocking ocsp is enough to reset that cache, will your Mac boot normally if you redo the signing routine like that?

Anyway ad hoc signing seems like a very convoluted solution that also wants SIP off...

I booted in safe mode probably 30 times tried ocsp blocking, deleting/replacing clrs db and it never flushed this hiddden db. The date changing and safe mode made no difference. The original pkg wouldn’t complete install (even in safe mode) and the kexts were inoperable.

I’m happy to report I have no issues since fresh install, blocking ocsp and migration assistant.