Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

arsradu
arsradu
Posted
Posted

So where the hell does this nvda_drv=1 comes from ? I don't get it.

 

I have no arguments in Boot section. I set all of them in custom entries for each OS X version like this :

For Mavericks :

<key>AddArguments</key>
<string>nvda_drv=1</string>
<key>Disabled</key>
<false/>
<key>FullTitle</key>
<string>OS X Mavericks</string>
<key>Ignore</key>
<false/>
<key>InjectKexts</key>
<true/>
…

For Yosemite :

<key>AddArguments</key>
<string>kext-dev-mode=1 nvda_drv=1</string>
<key>Disabled</key>
<false/>
<key>FullTitle</key>
<string>OS X Yosemite</string>
<key>Ignore</key>
<false/>
<key>InjectKexts</key>
<true/>
…

For El Capitan :

<key>AddArguments</key>
<string>rootless=0</string>
<key>Disabled</key>
<false/>
<key>FullTitle</key>
<string>OS X El Capitan</string>
<key>Ignore</key>
<false/>
…

And still, if NVIDIA Web drivers is selected, nvda_drv=1 is added (twice for Mavericks & Yosemite) on next reboot whatever the OS I choose causing issues with OS X 10.11. :wacko:

Whatever it is with Clover adding that flag, it was there before PB5/DB7 updates. So I don't think that's what's causing the issues. Also, as Slice mentioned above, the kernel will only read one of them. That doesn't really mean everything is perfect, but it means that no matter how many they are, the system will read only one. So, either if it's coming from you, the user, adding that flag manually in config, or from Nvidia driver, adding that flag automatically, in the end, only one flag will be read by the kernel.

 

The issues with the latest updates of 10.11 are most likely related to the changes in graphics and they are causing issues with that nvda_drv=1 flag (again, added by the user or by the driver itself). So, it doesn't really matter what Clover should have done for this circumstance, it couldn't have caused the issues we're having now.

Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted

So actually, that means that this is the Nvidia driver the sole and unique responsible for all of this. That would also explain why uninstalling it for good is the only way to get rid of all of those issues too.

 

I don't know if something change in the way OS X 10.11 manage the graphics but I would tend to think it's an NVIDIA problem versus an OS X one since even adding nvda_drv=0 doesn't change anything at all. I may be wrong but setting it that way should work and switch to OS X default drivers ?

 

I'm just wondering if nvda_drv=1 is still a relevant argument and to be honest, wondering if it ever was ?

Link to comment
Share on other sites
D-an-W
D-an-W
Posted
Posted

This look new with latest PB!

Dans-Mac-mini:~ Dan$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
Link to comment
Share on other sites
smolderas
smolderas
Posted
Posted

 

This look new with latest PB!

Dans-Mac-mini:~ Dan$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Are these results from a hackintosh or a real mac?

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Are these results from a hackintosh or a real mac?

here's my result from a real Mac :P

$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).
 
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
 
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
But, just between testing atm.
Link to comment
Share on other sites
tluck
tluck
Posted
Posted

OK, I remember what is the problem with info.plist patching.

The patching is occurred in kernelcache. But if you want to change DeviceID then assumed that the kext.info.plist doesn't contain your numbers.

So this kext will not loaded into kernelcache and consequently there is no to patch. Because the kext initially is not matching to your device!

 

As a workaround dmazar proposed to boot twice. First time without cache and force load this kext. It will be patched and included into kernel cache for the next restart. Being in system delete old kernel cache.

Second time you may boot with new kernelcache.

 

I think FakeID is the better procedure but your DSDT should have correct entry for the device. Usually Clover's DSDT patching will be enough for that.

 

These instructions are already in Clover v2 Instructions thread.             #48            

 

now i am more confused than ever on how to do InfoPlistPatch. i understand its "catch-22" in that Clover cant patch the kext unless its in the cache. so i can force the kext to load.  

 

However, I tried to put text characters into  and just convert from string to data and that did not seem to work. And when I look at your example in #48 shows the find text converted to hex couples in PlistEditor Pro? vs just the actual <integer>1</intern

 

 

Link to comment
Share on other sites
smolderas
smolderas
Posted
Posted

I have this in Config.plist currently to allow me to patch AppleHDA.kext

		<key>CSRActiveConfig</key>
		<string>0x67</string>
		<key>BooterConfig</key>
		<string>0x28</string>

I will try it with SIP enabled later.

So the clover settings must be out-of-sync with the setting according to Pike:

https://pikeralpha.wordpress.com/2015/08/19/csrutil-updated/

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Is anyone else getting a panic when waking from sleep with latest Public Beta?

 

Sleep works 100% in Yosemite and the previous El Capitan PB so I assume something has changed.

Mine doesn't even get into sleep mode...leave alone waking up from it. The only way that {censored}'s gonna wake up, is if you press the restart button.

 

But I am getting a LOT of kernel panics when booting up in normal mode. Strangely enough, not when booting in single-user mode.

Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted

 

I don't want to pollute this topic anymore but it doesn't really answer the question :P.

 

From what I see, it's a post-install script and the nvda_drv=1 argument should be "skipable" in some way at any moment which is not the case if you don't use NVIDIA driver Manager.

 

I suspect it's somewhere in the driver itself and that's the way the NVIDIA driver Manager communicate with it. Not via the nvram nor the bootloader.

 

Anyway, new version of webdrivers 346.03.01b07 solves the DB7 and PB5 issues :D !

  • Like 2
Link to comment
Share on other sites
fantomas
fantomas
Posted
Posted

but it doesn't really answer the question :P.

 

sorry but it is the answer… the web driver installer will automatically inject the nvda_drv=1 boot flag in nvram.plist

 

292952Capturedcran20150821000502.png

 

 

I just have -v as boot-flag but look:

 

8:490  0:000  found boot-args in NVRAM:nvda_drv=1, size=10

8:490  0:000  ...found arg:nvda_drv=1
8:490  0:000  ...adding arg:nvda_drv=1
  • Like 1
Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted

So how could you explain that with :

 

• No nvram.plist at the root of my El Capitan partition

• No nvda_drv=1 in config.plist (at least in OS 10.11 custom entry)

• Webdrivers installed but disabled in El Capitan

 

nvda_drv=1 still appear at every boot and is still loaded even after I removed it from Clover's Options menu ? :wacko:

 

That would mean that Clover reads my nvram.plist from the Yosemite partition which is located in another drive…

 

Don't get me wrong, I'm not saying that this is Clover or webdrivers fault and it's probably my mistake but I don't know where and why.

 

That's why I try to understand what's going on :P.

  • Like 1
Link to comment
Share on other sites
fantomas
fantomas
Posted
Posted
  • nvram.plist is a hidden file
  • does not have to be in... as it's injected in your nvram.plist
  • uninstall web driver and the flag will be gone
That would mean that Clover reads my nvram.plist from the Yosemite partition which is located in another drive… 

 

 

that’s it!

 

Don't get me wrong, I'm not saying that this is Clover or webdrivers fault and it's probably my mistake but I don't know where and why.

 

 

but it’s web driver the culprit... just uninstall the webdriver and you’ll see!   :yes:

 

419690Capturedcran20150821003624.png

  • Like 1
Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted

Well… too late :D

 

I've re-installed new version of webdrivers so I can't check this anymore. And guess what ? I now have an nvram.plist at the root of El Capitan partition !

 

But I'm sure I hadn't before and it makes me a bit confuse about that. I believed that nvram.plist was created by the bootloader, not by the webdrivers installer and also that the nvram.plist was only read from the boot drive…

 

Anyway, I don't really care. I have polluted this topic way too much with my little problems ;).

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

That would mean that Clover reads my nvram.plist from the Yosemite partition which is located in another drive…

Clover will load the latest NVRAM.plist. NVRAM is intended to be global (eg. on a real Mac there is only one NVRAM store for the entire machine).

 

So.. if you:

- install 10.11... it will likely write a new nvram.plist

- next boot (no matter which system), Clover will use nvram.plist from volume 10.11

- then boot 10.10... it will use nvram.plist from 10.11 volume

- then install the nvidia drivers (or update them)...

- reboot... nvram.plist on the 10.10 volume will be updated

- next boot (no matter which system) uses nvram.plist from 10.10 volume (now has nvda_drv=1)

- so... if you boot 10.11, you'll find nvda_drv=1 set

 

In other words, it works exactly like real NVRAM and exactly like a real Mac.

 

You cannot have different NVRAM contents for each bootable volume on a real Mac either.

 

Work around:

- make sure nvda_drv=1 is NOT set in any nvram.plist

- use Clover config.plist to set nvda_drv=1 as desired

- be careful to clear nvda_drv=1 in NVRAM boot-args before shutting down/restarting if you use the Nvidia driver installer

  • Like 5
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...