Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

Hi Sergey. :) So any idea for my hardware then? I don't have nvda_drv in nvram plist. So, trying to remove it from there...didn't do much for me.

 

I'm not sure this is NVRAM related (although, of course, I might be wrong). The reason why I'm not sure this is NVRAM related is that when I removed rootless=0 from config, I didn't have this issue of still seeing it when booting up. I removed it, it was removed for good. So...why would it be any different for nvda_drv=1? Any idea?

I see you are using EmuVariableUefi-64,efi

but I think you have hardware NVRAM and should exclude this driver.

 

Something new I found in you dumps

2:339  0:000   Adding Key: rc_imgsrc_info: Size = 98, Data: 

I never saw such variable and don't know what it means.

 

And one more question

12:980  0:000  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\10.11
12:989  0:009    Extra kext: EFI\CLOVER\kexts\10.11\CodecCommander.kext
12:998  0:008    Extra kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext
13:002  0:004    Extra kext: EFI\CLOVER\kexts\10.11\realtekALC.kext

Is this a problem of your reboot?

Link to comment
Share on other sites

I see you are using EmuVariableUefi-64,efi

but I think you have hardware NVRAM and should exclude this driver.

 

Something new I found in you dumps

2:339  0:000   Adding Key: rc_imgsrc_info: Size = 98, Data: 

I never saw such variable and don't know what it means.

 

And one more question

12:980  0:000  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\10.11
12:989  0:009    Extra kext: EFI\CLOVER\kexts\10.11\CodecCommander.kext
12:998  0:008    Extra kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext
13:002  0:004    Extra kext: EFI\CLOVER\kexts\10.11\realtekALC.kext

Is this a problem of your reboot?

 

Ok, I'll try to remove EmuVariableUefi-64 and see what happens. 

 

For imgsrc_info, I found this. I'm not sure how much it helps though... 

 

You're right. I forgot to remove those from EFI since it's not using them anyway. I'm not sure if that's the source of the reboots. But I'm trying now.

Link to comment
Share on other sites

0x1 = SIP disabled + Allows Unsigned Kexts

0x3 = SIP disabled + Allows Unsigned Kexts + Allows unrestricted Access to FileSystem

 

so:

0x0 = SIP Fully Enabled
0x1 = 0x65 = Enable unsigned kexts + Enable NVRAM edit + Disable /System access
0x3 = 0x67 = Enable unsigned kexts + Enable NVRAM edit + Enable /System access

correct?

  • Like 1
Link to comment
Share on other sites

so:

0x0 = SIP Fully Enabled
0x1 = 0x65 = Enable unsigned kexts + Enable NVRAM edit + Disable /System access
0x3 = 0x67 = Enable unsigned kexts + Enable NVRAM edit + Enable /System access

correct?

Well, short answer, no. :)

 

0x1 enables only one bit: CSR_ALLOW_UNTRUSTED_KEXTS.

 

0x65 enables: 

CSR_ALLOW_UNTRUSTED_KEXTS

CSR_ALLOW_TASK_FOR_PID

CSR_ALLOW_UNRESTRICTED_DTRACE

CSR_ALLOW_UNRESTRICTED_NVRAM

 

0x3 enables:

CSR_ALLOW_UNTRUSTED_KEXTS

CSR_ALLOW_UNRESTRICTED_FS

 

0x67 enables:

CSR_ALLOW_UNTRUSTED_KEXTS 

CSR_ALLOW_UNRESTRICTED_FS
CSR_ALLOW_TASK_FOR_PID
CSR_ALLOW_UNRESTRICTED_DTRACE
CSR_ALLOW_UNRESTRICTED_NVRAM
 
If, by equal, you mean they do similar things and they have things in common, then yes, they do. If you mean they are doing the same things, no, they don't. Some of them will enable features that the other ones will not.
  • Like 1
Link to comment
Share on other sites

But for new installation? We need to inject fakesmc from? (If we can not from EFI)

For new installations, I would stick to DP3 or PB1, and upgrade after every kext (especially FakeSMC) is in place and properly set up.

 

Meaning you use the USB stick with DP3 or PB1 to install the OS (make sure Clover is the latest version). When it's done, you move your custom kexts into L/E for example (don't forget to set proper permissions for each one of them), then reboot and gradually upgrade to the latest version.

Link to comment
Share on other sites

I noticed a really annoying issue when using Clover Configurator 4.23.0 (and more likely all versions) and new arguments in RtVariables like BooterConfig & CsrActiveConfig :

 

If you open your config.plist with it and make any change to it, it will just wipe out the new edits in RtVariables, restoring SIP back to default mode : enabled

 

Can someone confirm this ?

Link to comment
Share on other sites

You need to wait update of CC.

This forum is not related with CC support.

 

I can confirm your problem, from long time I use light config plist and I open only with text edit.

 

I agree but since CC is used by lot of person (including me) and that this forum is related to new arguments that directly concern Clover, I think that info could interest some of them. It's not a matter of CC support and I don't ask here if and when it will be fixed !

 

No offense, but let's not forget that all this new stuff about SIP is complex enough to not focus only on what is related to or not...

 

Anyway, thanks for the confirmation :D.

  • Like 1
Link to comment
Share on other sites

I agree but since CC is used by lot of person (including me) and that this forum is related to new arguments that directly concern Clover, I think that info could interest some of them. It's not a matter of CC support and I don't ask here if and when it will be fixed !

 

No offense, but let's not forget that all this new stuff about SIP is complex enough to not focus only on what is related to or not...

 

Anyway, thanks for the confirmation :D.

I think such questions should be addressed to this thread      Clover Third-Party Tools     but there is no discussion.

Open new thread for CC discussion? If the author wants to discuss...

Link to comment
Share on other sites

I think such questions should be addressed to this thread      Clover Third-Party Tools     but there is no discussion.

Open new thread for CC discussion? If the author wants to discuss...

 

OK, thanks. I will (try at least :D).

 

But this was not a question actually. I mean, I just wanted to share the info and have a confirmation, nothing more ;). Sorry if it was off-topic.

Link to comment
Share on other sites

I see you are using EmuVariableUefi-64,efi

but I think you have hardware NVRAM and should exclude this driver.

 

Something new I found in you dumps

2:339  0:000   Adding Key: rc_imgsrc_info: Size = 98, Data: 

I never saw such variable and don't know what it means.

 

And one more question

12:980  0:000  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\10.11
12:989  0:009    Extra kext: EFI\CLOVER\kexts\10.11\CodecCommander.kext
12:998  0:008    Extra kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext
13:002  0:004    Extra kext: EFI\CLOVER\kexts\10.11\realtekALC.kext

Is this a problem of your reboot?

Hi, Sergey.

 

I removed the kexts from EFI/CLOVER/kexts. That was a mistake anyway. But it didn't make any difference on the reboot issues. I also uninstalled EmuVariableUefi-64 and everything was still ok. So probably it wasn't necessary from the very beginning. Thank you for the tip. :)

 

Now, I tried something. And I think this has something to do with the nvda_drv boot flag.

 

If I add nvda_drv=1 (even if it's just for one time, in Clover Options, on boot time), the boot is successful every time. I added it now manually in config.plist so that I don't need to do it every time I start my computer.

If I don't add that flag, it will create reboot problems 90% of the times. The computer reaches the login screen, freezes for a second, then reboots. Next time it boots up, usually everything is ok and I can reach the Desktop. Worst case scenario, it will reboot one more time.

 

So now, even though the Nvidia driver is installed, it's not in use. I'm using the default OS X driver with nvda_drv=1 manually added in Clover config, since, enabling the proprietary driver from Nvidia causes the shutdown issues I told you about (computer doesn't shut down completely).

It's a strange workaround but it seems to work ok for now. Of course, it doesn't make much sense to have nvda_drv=1 if you're not actually using the Nvidia driver. But, so far, it's the only way I can have successful shutdowns and no reboots on startup.

 

So these are my results after applying your suggestions.

 

Now, I'll let you decide if this has anything to do with Clover or not, and if it does, maybe there's a fix for it.

 

Again, thank you very much for your help. :)

Link to comment
Share on other sites

Fix what? Usage of nvda_drv=1?

I don't know. :)) I just thought it's a bit weird that when I add that boot flag, even if I'm not using the actual Nvidia driver, everything is ok as far as startup goes. But if I remove the flag, the reboot issues start.

 

I don't know if it's got anything to do with Clover, that's the thing. Maybe it doesn't. Only you can decide that. I just mentioned my results in case it might have something to do with it and maybe there is something that can be done to fix this issue.

 

But I guess it's not related to Clover so, really, if you've got any idea what could cause this, please, let me know. If not, then I guess I'll just try re-enabling the Nvidia driver later on? Maybe it's from the OS itself.

Thank you. :)

Link to comment
Share on other sites

×
×
  • Create New...