Slice Posted August 4, 2015 Share Posted August 4, 2015 I am using AMD Radeon. Link to comment Share on other sites More sharing options...
calibre™ Posted August 5, 2015 Share Posted August 5, 2015 Just some clarification: 0x00 = SIP enabled + Disables System access 0x67 = SIP disabled + Enables System Access What about: 0x1 = SIP disabled + Enables System Access 0x3 =? 1 Link to comment Share on other sites More sharing options...
arsradu Posted August 5, 2015 Share Posted August 5, 2015 0x1 = SIP disabled + Allows Unsigned Kexts 0x3 = SIP disabled + Allows Unsigned Kexts + Allows unrestricted Access to FileSystem 1 Link to comment Share on other sites More sharing options...
Slice Posted August 5, 2015 Share Posted August 5, 2015 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 More sharing options...
arsradu Posted August 5, 2015 Share Posted August 5, 2015 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 More sharing options...
Slice Posted August 5, 2015 Share Posted August 5, 2015 For imgsrc_info, I found this. I'm not sure how much it helps though... Thanks, I will look what is it. Link to comment Share on other sites More sharing options...
calibre™ Posted August 5, 2015 Share Posted August 5, 2015 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? 1 Link to comment Share on other sites More sharing options...
arsradu Posted August 5, 2015 Share Posted August 5, 2015 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. 1 Link to comment Share on other sites More sharing options...
calibre™ Posted August 5, 2015 Share Posted August 5, 2015 Gotcha! Thanks arsradu Link to comment Share on other sites More sharing options...
iRipper Posted August 5, 2015 Share Posted August 5, 2015 So after reading a lot of this I have a noob question: Will kext injection ever be possible from EFI? Link to comment Share on other sites More sharing options...
Slice Posted August 5, 2015 Share Posted August 5, 2015 So after reading a lot of this I have a noob question: Will kext injection ever be possible from EFI? No for now. A question for a future. 2 Link to comment Share on other sites More sharing options...
Simonej Posted August 5, 2015 Share Posted August 5, 2015 No for now. A question for a future. But for new installation? We need to inject fakesmc from? (If we can not from EFI) Link to comment Share on other sites More sharing options...
calibre™ Posted August 5, 2015 Share Posted August 5, 2015 But for new installation? We need to inject fakesmc from? (If we can not from EFI) its still a long way before the release. dont worry 1 Link to comment Share on other sites More sharing options...
arsradu Posted August 5, 2015 Share Posted August 5, 2015 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 More sharing options...
Slice Posted August 5, 2015 Share Posted August 5, 2015 But for new installation? We need to inject fakesmc from? (If we can not from EFI) Boot into single mode. mount -uw / kextutil -v /FakeSMC.kext exit 4 Link to comment Share on other sites More sharing options...
polyzargone Posted August 5, 2015 Share Posted August 5, 2015 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 More sharing options...
Simonej Posted August 5, 2015 Share Posted August 5, 2015 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. 3 Link to comment Share on other sites More sharing options...
polyzargone Posted August 5, 2015 Share Posted August 5, 2015 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 . 1 Link to comment Share on other sites More sharing options...
Slice Posted August 6, 2015 Share Posted August 6, 2015 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 . 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 More sharing options...
polyzargone Posted August 6, 2015 Share Posted August 6, 2015 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 ). 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 More sharing options...
arsradu Posted August 6, 2015 Share Posted August 6, 2015 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 More sharing options...
Slice Posted August 6, 2015 Share Posted August 6, 2015 Fix what? Usage of nvda_drv=1? Link to comment Share on other sites More sharing options...
arsradu Posted August 6, 2015 Share Posted August 6, 2015 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 More sharing options...
WaldMeister Posted August 6, 2015 Share Posted August 6, 2015 Hi Slice, On El Capitan Public Beta 4 i had to replace OsxLowMemoryFixDrv with OsxAptioFixDrv, else boot would hang at the point where Clover loads the OS. Any way i can troubleshoot this? Link to comment Share on other sites More sharing options...
Slice Posted August 6, 2015 Share Posted August 6, 2015 For my experience OsxLowMemoryFixDrv never worked and always can be replaced by OsxAptioFixDrv. Don't know what is the key idea of the LowMemFix. 1 Link to comment Share on other sites More sharing options...
Recommended Posts